If I had to decide, and luckily I don't have to ;-), I would skip inbuilt functions. According to the described usecase the reason is that they are supposed to be "natively available" at the executor side. So they could be written in the code directly or wrapped in a user function. From a more general viewpoint because they're supposed to be native and thus could possibly be implemented at a lower level (rts) which would mean that there is possibly no Xquery code to serialize. Thus out of your list my choice would fall on
inspect:serialize(local:f#0) inspect:serialize(function() {1})
But honestly I don't know how hard it is to make the function selectively applicable to only user functions and anonymous functions. So please consider this to be just loud thinking. Cheers, Marco.
On 06/11/2014 15:47, Christian Grün wrote:
One more thing we have to be aware of: In XQuery, we have lots of different function items. I wonder if we should support all of these?
declare function local:f() { 123 }; inspect:serialize(map {}), inspect:serialize(local:f#0), inspect:serialize(substring#2), inspect:serialize(function() {1})
On Wed, Nov 5, 2014 at 3:23 PM, Marco Lettere marco.lettere@dedalus.eu wrote:
Hello all, just out of curiosity, would it be too hard to have a serialization tool for functions that does more or less the inverse of inspect:functions i. e. given a function item returns the full function code? The use case is that I want to send out a client:execute request that is a XQuery script where functions can be attached at runtime selecting them out of a "toolbox" xqm module. And of course I don't want to manually parse the xqm to cut out the required function which could be done but is not very elegant.
Example:
declare function local:f($i as xs:integer) as xs:integer{ $i + 1 };
inspect:serialize(local:f#1)
would yield the string "declare function local:f($i as xs:integer) as xs:integer{ $i + 1 };"
I've seen that even if it is not possible to serialize or cast to string a function item, if the function is assigned to a map, calling map:serialize yields something similar to the full function code. So I thought maybe the serialization mechanism is already in place and would just need a bit of generalization. Regards, Marco.