Re: [xsl] Higher-Order Functions in XPath 2.0

Subject: Re: [xsl] Higher-Order Functions in XPath 2.0
From: Joerg Pietschmann <joerg.pietschmann@xxxxxx>
Date: Thu, 17 Jan 2002 16:26:57 +0100
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


Current Thread