Subject: RE: [xsl] saxon:expression and functional argument issue ... From: "Michael Kay" <michael.h.kay@xxxxxxxxxxxx> Date: Wed, 16 Jan 2002 12:04:36 -0000 |
> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
[xsl] saxon:expression and function, Gunther Schadow | Thread | [xsl] creating test xml docs from a, jasonp |
Re: [xsl] how to make data fit in a, Joerg Pietschmann | Date | RE: [xsl] alternating bg colour in , Andrew Welch |
Month |