[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: mapping (Was: Re: Re: . in for)
> 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|