RE: mapping (Was: Re: [xsl] Re: . in for)

["Michael Kay" <michael.h.kay@xxxxxxxxxxxx>]

> 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