This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: mapping (Was: Re: Re: . in for)
- From: "Michael Kay" <michael dot h dot kay at ntlworld dot com>
- To: <xsl-list at lists dot mulberrytech dot com>
- Date: Fri, 11 Jan 2002 15:26:26 -0000
- Subject: RE: mapping (Was: Re: [xsl] Re: . in for)
- Reply-to: xsl-list at lists dot mulberrytech dot com
> Indeed you are right, the expressions within predicates are
> lambda expressions (not sure about steps, i'm too lazy to
> look up the definition). They are, however, somewhat special
> as they can have only one parameter, the ".".
When I first did saxon:expression, I decided that the vast majority of use
cases could be handled with "stored expressions" rather than full lambda
expressions, that is, lambda expressions with a single implicit argument of
".". I have found one exception since, namely the transitive closure
function. I suspect, though, that a restricted facility that meets 90% of
the requirement might have slightly more chance of acceptance. (Not that I
have high hopes for any of this getting into the current version).
>
> That's correct. But we don't need to have lambda expressions as
> XPath data types as long as we don't want to pass them around
> in variables and parameters.
That's an interesting observation - I hadn't realised the two aspects could
be separated. But don't most of the use cases require passing of a function
as an argument?
> With a functional approach and lambda expressions, even if they
> have to be literals (no full data types), XSLT could easily
> define a XSLT specific function
> concat-for(expression,delimiter,sequence) => string
> to be used like
> concat-for(expression(floor($x),x),':',$stuff)
Now you're confusing me. How can "expression" be supplied as an argument to
a function if expressions are not a data type?
> The lambda expression syntax might be somewhat tricky to get
> right, "expression(expr,arg,...)" may be too much like a function
> invocation. Perhaps #(arg1,arg2,...,expr) ?
Syntax is always difficult to get right! I've suggested in the past using
[arg1, arg2; expr]
(But there are people in the XQuery WG who like keyword-based syntax and
mock this kind of thing as "line noise". Those people might prefer something
like "with $arg1, $arg2 return expr". You could give examples using both
syntaxes to avoid that criticism.)
Then the predicate a[x=2] becomes shorthand for
select(a, [$p; $p/x=2])
while:
for $x in X return $x/y
becomes shorthand for
map(X, [$x; $x/y])
and
some $x in X satisfies f($x)
means
exists(select(X, [$x; f($x)]))
and
a/b
is (roughly speaking) shorthand for
select(children(.), [$c; name($c)='b'])
You get a spin-off of being able declare range variables in a predicate:
customer[$c; exists($c/orders[preferred-customer=$c])]
>
> Next point: having lambda expressions even as data types is not the
> same as having higher order functions. There is a hierarchy of
> complexity:
> 1. Literal lambda expressions do not add complexity to the current
> draft, as we can claim for all practical purposes that we have them
> already. Especially they do not threaten existing optimizations or
> the possibility to compile XSLT programs into other programming
> languages.
> 2. Lambda expressions as data types. I don't think this is a big step
> from level 1 as implementors are likely to invent a framework for
> implementing the various "for" operators which involves a sort of
> function objects. If we have them we can as well pass them around
> elsewhere. However, it will inhibit writing compilers from XSLT to
> languages which have only statically bound functions like FORTRAN77,
> you'd need function pointers or OO-objects with virtual methods.
> 3. Higher order functions. I'm walking on thin ice here but i
> believe this requires the possibility to compose lambda expressions
> from run-time supplied data.
My understanding is that "higher order functions" means functions that take
functions as their arguments or return functions as their result. That's (2)
above. I think the evaluate() capability is technically reflexion: the
ability to manipulate source language expressions from within the language.
>
> Next: use cases
> As for lambda expressions as literals, there is no need to present
> any. What's we should do is convince the WG that it is better for
> the modularity and extensibility of XPath and related standards
> to have lambda expression literals and functions which can take
> them as arguments rather than to invent new "for"-like operators
> every time someone feels the need to do something which involves
> iterating a sequence.
The one we are currently inventing is "distinct" (select the items in $x
that have distinct values for f(x)). So it might be a good idea to take that
as your exemplar, pointing to the (known) limitations of the current
distinct-values() function.
distinct(employee, [$emp; $emp/@SSN])
Mike Kay
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list