Re: Tip?

Adam, once more thank you for your valuable suggestion: it lead me to find out that the BaseX function "xquery:eval" supports exactly what you described - injection of variable values (which may just as well be function items) via "declare variable $foo external" + an argument map of explicit bindings. And this approach of using an external variable is of course much more natural and elegant than the import I had resorted to.
Michael, I wonder if your worries about preventing optimization are not taken care of by the approach BaseX takes. To recapitulate: the BaseX approach is to supply *explicit* bindings to external variables declared within the expression; the bindings are passed in via a map argument providing the name/value pairs. Example:
let $x := 1 return
xquery:eval('declare variable $y external; $y + 1', map{'y': $x})
So I would imagine that the optimizer is in no way disturbed, as the binding is explicit and therefore similar to any ordinary use of the variable.
I ASK MYSELF: Is the BaseX approach not a candidate for an EXPath standardization?

[If I read the eXist example correctly, it is very similar, but does not use a map, but a map appears to me as the most intuitive representation of bindings.]


 

    Michael Kay <mike@saxonica.com> schrieb am 14:07 Donnerstag, 25.August 2016:
 

 


> On 25 Aug 2016, at 12:50, Adam Retter <adam@exist-db.org> wrote:
> 
> So... the way I would explain it for eXist is, that the util:eval
> function example that I gave, executes code within the current XQuery
> Context, so everything in the host XQuery is available to the
> dynamically evaluated query. We also have a version of util:eval where
> you can request a new context if you wanted isolation.
> 

By contrast, saxon:evaluate() has always allowed access to user-defined functions declared in the query, but not to variables. Historically this was because variables were often optimized away during compilation, therefore not available at run-time, and we didn't want to forgo this optimization opportunity just because someone might do an eval() to access the variables at run-time. In principle the same argument could apply to functions, once we started doing function inlining; but we have to preserve functions for fn:function-lookup anyway.

Michael Kay
Saxonica