Some thoughts on eval()

In our wiki page for eval(), it is suggested that we model the function 
off of saxon:evaluate()
http://www.saxonica.com/documentation9.1/extensions/functions/evaluate.html

That function receives no variables from the context.  Anybody know why?
That function instead can optionally receive variables named $p1, $p2, ... 
by supplying second, third, ... params to saxon:evaluate().  It's a little 
odd that the variable numbering is off by one relative to the parameters, 
e.g. the second parameter to saxon:evaluate() is referenced using $p1, but 
whatever.

It may be that variables from the context were excluded from the 
evaluation to make sure they didn't conflict with $p1, $p2, etc., but if 
that's the only reason, it doesn't seem like a good enough one.

I'm not at all opposed to using some params to supply variables and their 
values.  However, an alternative second parameter would actually be a 
"context" expression.  The context expression would actually be evaluated 
first, and then the main eval expression would be evaluated in the context 
of the (first) node result of the context expression.

For example, I'd like to be able to say eval('concat(first, last)', 
'employees/person[1]')

To be clear, I actually want to invoke something more like "eval(keyExpr, 
concat(listExpr, '[', indexNum, ']'))", where the two parameters resolve 
to the string literals shown above.

Although it is legal in XPath 2.0, it is not legal in XPath 1.0 to use a 
function in a location path step after the first step.  To be clear, XPath 
1.0 syntax (inexplicably) does not allow expressions such as 
"employees/person[1]/concat(first, last)".  The eval() function with a 
second context expression parameter would enable XPath 1.0 authors to 
perform this type of operation.

It seems like we should be allowing this as a second optional parameter, 
at least for XPath 1.0, and it also seems like we should not use 
parameters to define variables for the main expression but instead let the 
expression(s) obtain variables from the evaluation context.  Feedback?

Thanks,
John M. Boyer, Ph.D.
Distinguished Engineer, IBM Forms and Smarter Web Applications
IBM Canada Software Lab, Victoria
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Blog RSS feed: 
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw