This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Higher-Order Functions in XPath 2.0
- From: Joerg Pietschmann <joerg dot pietschmann at zkb dot ch>
- To: XSL List <xsl-list at lists dot mulberrytech dot com>
- Date: Thu, 17 Jan 2002 16:26:57 +0100
- Subject: Re: [xsl] Higher-Order Functions in XPath 2.0
- Organization: ZKB
- Reply-to: xsl-list at lists dot mulberrytech dot com
Hi Dimitre,
sorry, i'm late.
Some comments, just in case you want to amend your proposal
or you are asked to clarify some points:
Point 3.) This essentially says there is currently no facility
to iterate over two or more sequences in parallel rather than
on the cartesian product. This is especially bad because
there is no reasonable way to emulate this using the "for"
operator.
Point 6.) Illustrative examples could be
o sorting by $price*$volume
o grouping or eleminating duplicates by having
$e1/package=$e2/package and $e1/local-name=$e2/local-name
as equality definition. This has the advantage over using
concat(package,'#',local-name) as key in that there is no
longer a guard string required in order to avoid spurious
matches.
Point 5.) My formulation of the concerns expressed here:
o There are deficiencies in the area of sequence processing
(and other areas).
o In order to fix this deficiencies, operators similar to
"for", "some" or "every" would have to be designed, which
has impact on the grammar.
o This in turn forces such extensions into the language core,
apart from causing potentially major rewrites of existing
parsers.
o Furthermore, with more and more "for"-like constructs it
becomes harder to avoid ambiguities and other parsing
problems.
o OTOH, with a functional oriented syntax and higher order
functions these extensions can be kept modular and don't
require further changes in the grammar.
o While a functional syntax might not be intuitive to anyone
but mathematicans, at least it makes it easier to counter
accusations of perpetrating "cultural chauvinism" :-)
Also, if this helps, both the C++ STL and Common Lisp provide
easily accessible functionality for solving problems mentioned
in points 3 and 6. This indicates there *is* some need.
There is also the observation that nearly all the functionality
of operators in the XPath 2.0 specification is backed up by
a corresponding function definition in the F&O document, with
the notable exceptions of the "for", "some", "every" and "instance
of" and "if" operators. If the commitee provided backing functions
for this constructs too, they'd see clearly there is already
functionality involving higher order functions present.
Regards
J.Pietschmann
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list