[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: mapping (Was: Re: Re: . in for)

Subject: RE: mapping (Was: Re: Re: . in for)
From: "Michael Kay" <michael.h.kay@xxxxxxxxxxxx>
Date: Fri, 11 Jan 2002 15:26:26 -0000
walking on thin ice expression
> 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])

  for $x in X return $x/y
becomes shorthand for
  map(X, [$x; $x/y])

  some $x in X satisfies f($x)
  exists(select(X, [$x; f($x)]))

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

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.