Re: mapping (Was: Re: [xsl] Re: . in for)

[Joerg Pietschmann <joerg.pietschmann@xxxxxx>]

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
expressions:
  <xsl:template match="some-stuff">
    <xsl:variable name="start-pos" select="@offset"/>
    <xsl:apply-templates>
      <xsl:with-param name="selector"
          select="expression(substring($arg,$start-pos,1),arg)/>
    </xsl:apply-template>
  </xsl:template>
  <xsl:template match="element-with-attr"> 
    <xsl:param name="selector"/>
    <xsl:copy>
      <xsl:copy-of select="map($selector,@*)|node()"/>
    <xsl:copy>
  </xsl:template>
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
  again.
- Lambdas won't solve world hunger. :-)

Regards
J.Pietschmann

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list