[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: Joerg Pietschmann <joerg.pietschmann@xxxxxx>
Date: Thu, 10 Jan 2002 18:09:29 +0100
lamda expressions
Jeni Tennison <jeni@xxxxxxxxxxxxxxxx> wrote:
[about lamda expressions]
> I think it gives
> you lambda expressions in a limited set of circumstances, without
> adding lambda expressions as objects in the data model

Well, for a starter, there are some sort of lambda expressions
already in the draft:
  for $e in $stuff return $e*2
This is equivalent to LISPisch
 (mapcar '(lambda (e) (* e 2)) stuff)
or in a form more amenable to more conventional programmers
 map( expression(e*2,e), $stuff)
(Here, expression() takes the the expression as first, names of
the variables bound as parameters as further parameters. There
may be more intuitive ways to deal with lambdas taking more than
one parameter.)

Having lambda expressions as data types means that you can
bind them to variables, pass them as parameters and have
user-defined functions that take and produce such
  <xsl:template match="some-stuff">
    <xsl:variable name="start-pos" select="@offset"/>
      <xsl:with-param name="selector"
  <xsl:template match="element-with-attr"> 
    <xsl:param name="selector"/>
      <xsl:copy-of select="map($selector,@*)|node()"/>
Note: The example assumes static binding of $start-pos in the
lambda expression passed to the second template (does someone
vote for dynamic binding? :-)

It's not necessary for lambdas to be full data types in order
to have a lexical representation. However, some people might take
the name "data model" more literally and be uncomfortable
with formulations like "the map() function has a parameter
of type lambda expression as the first argument". Since function
parameters have to have a type, this may be difficult to
sell. For the "for" operator above, this is hidden in the
grammar (i assume), and because of the baroque design nobody
will ever say "the 'for' operator takes a lambda expression as
it's first|third operand", so the problem doesn't surface here.

Sidenote: Intuition often runs counter modularity and orthogonality
of concepts. I mean, the "for" operator is cool but it doesn't help
us in situations which could be easily solved with lamda expressions,
i.e. defining the equivalent of mapconcat and such.

Whether you have lambda expressions as full data type or only
a lexical representation, there is still the question of the
possibility of composing lambdas at runtime from user data. That's
equivalent to having an evaluate() function (i think). I'll let
Dimitre comment on this, as he seems to be more fluid with this
than i am.

Well, the conclusion in less convoluted form:
- There is no need to have a lambda expression data type or function
  objects in order to have them and taking advantage of them.
- Having lambdas even without being a data type makes XPath easier
  to extend: no need for inventing zillions of "for" like operators
  and cluttering the grammar. Better modularity.
- Hiding lambda-like semantics in other definitions is not what i
  would like.
- Having lambdas as data type could be interesting. Grab the spec
  from some Common LISP documentation, no need to reinvent the wheel
- Lambdas won't solve world hunger. :-)


 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.