This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: saxon:expression and functional argument issue ...


> But -- still recovering from our intense dynamic scoping
> battle few weeks ago -- I can't resist noting certain
> things that pertain to the discussion. Saxon:assign being
> the most outstanding one of course, but here is another
> little more subtle one:

saxon:assign was an experiment. I don't encourage anyone to use it; I
implemented it in order to discover whether it would make some things
possible to do with XSLT that were otherwise impossible, and to discover
whether it would have any serious impact on the ability to do optimizations.
Frankly, the experiment has been inconclusive. The art of writing recursive
templates has advanced considerably since I did it, this reducing the
requirement, but I haven't yet found an optimization that I want to do that
becomes impossible because of saxon:assign, so I haven't felt any need to
withdraw it. I have seen some over-the-top abuses of saxon:assign to write
completely procedural code; but if that's what people want to do, I'm not
going to play the role of thought-police. And there are many functional
languages that manage to accommodate assignment.
>
>  > saxon:expression(string)
>
> > The supplied string must contain an XPath expression. The result of
> > the function is a stored expression, which may be supplied as an
> > argument to other extension functions such as saxon:eval(),
> > saxon:sum() and saxon:distinct(). The result of the expression will
> > usually depend on the current node. The expression may contain
> > references to variables that are in scope at the point where
> > saxon:expression() is called: these variables will be
> replaced in the
> > stored expression with the values they take at the time
> > saxon:expression() is called, not the values of the variables at the
> > time the stored expression is evaluated. Similarly, if the
> expression
> > contains namespace prefixes, these are interpreted in terms of the
> > namespace declarations in scope at the point where the
> > saxon:expression() function is called, not those in scope where the
> > stored expression is evaluated.
>
> So really what expression does is to create a functional argument
> and return it. From that point on you can pass it into other
> functions to use it. But, here is the thing: any free variables
> in the functional argument are bound to the current value assignments
> at the time the funarg is executed. That means, it's as if all of
> those free variables have become implicit parameters to the lambda
> object produced by the expression function.

Saxon:expression was never intended to be a lambda-expression. I did
consider implementing lambda expressions (in which those variables that were
intended to be function arguments were identified as such), but decided
there wasn't much need; nearly all use cases worked just fine using the
context node as the only (implicit) argument.
>
> I do not want to convey any blame on Mike Kay at all, but to
> the other side: in a world where serious XSLT processors offer
> assignment side-effects, and functional arguments of a kind the
> world hasn't seen since 1978 or longer...

I don't accept the criticism that binding variables at the time the
expression is created is somehow "incorrect". It's a useful mechanism, and
is necessary in particular because there is no way of "fixing" a node-set
value within the expression other than by binding a variable (node-sets
cannot be expressed as literals). (In the SQL PREPARE statement, which I
modelled this on, you can always fix values into the expression at PREPARE
time by using string-concatenation to build the prepared statement. You
can't do that with XPath because there's no way of expressing a node-set as
a literal value).

At the time I did it I was thinking of also providing free variables
(arguments) using either the SQL syntax "?", or perhaps using
variable-references of the form $1, $2, etc; but this never got implemented
(a) because I never found a strong need for it, and (b) because I was
reluctant to make any private extensions to the XPath grammar.

Mike Kay


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]