Feature Request: serializable functions

On Wed, Nov 5, 2014 at 3:23 PM, Marco Lettere <marco.lettere at 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.

On Thu, Nov 6, 2014 at 3:12 PM, Carl Leitner <litlfred at gmail.com> wrote: > On a somewhat related note, I assume that when compiling xquery you are > creating some kind of token stream. Would it be possible to add a function > like > xquery:tokenize ($query as xs:string) as item()* > which takes as input an xquery string and output the token string. > > Presumably this could be another route used to meet the use case discussed > below to select functions from a toolbox module. > > Here is an example of similar functionality in PHP: > http://php.net/manual/en/function.token-get-all.php > > Cheers, > -carl > > > On Nov 6, 2014, at 8:26 AM, Christian Grün <christian.gruen at gmail.com> > wrote: > > Hi Marco, > > You may be surprised (or not) that I thought about a similar > functionality. Indeed I wondered if we could allow function items as > input for client:query and xquery:evaluate. > > I like your idea of providing an explicit serialization function. For > several reasons, we cannot guarantee that the serialized > representation of an XQuery expression will always be executable. In > some case, it's even not possible because the optimizer creates new > expressions that have no counterpart in the original XQuery language. > If we provide an explicit function for serializing function code, > however, we'd be able to point this out. > > I have added a new GitHub issue [1]. > > Christian > > [1] https://github.com/BaseXdb/basex/issues/1021 > > > On Wed, Nov 5, 2014 at 3:23 PM, Marco Lettere <marco.lettere at 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. > >

On Wed, Nov 5, 2014 at 3:23 PM, Marco Lettere <marco.lettere at 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.

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 at 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.

>In some case, it's even not possible because the optimizer creates new

On 6 November 2014 16:34, Christian Grün <christian.gruen at gmail.com> wrote: > To complement this: In a straightforward implementation, the following > query… > > declare function local:f() { 123 }; > inspect:serialize(map {}), > inspect:serialize(local:f#0), > inspect:serialize(substring#2), > inspect:serialize(function() {1}) > > …would yield the following result: > > map { } > function() as item()* { local:f() } > function($string_0 as xs:string?, $start_1 as xs:double) as > xs:string { fn:substring($string_0, $start_1) } > function() as xs:integer { 1 } >

> Do you mean they invoke internal BaseX functions?

> If these serializations are post optimization does mean they MAY embody > assumptions about the context that are only valid at the moment they were > made?