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

[Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>]

Hi Joerg,

> Well, for a starter, there are some sort of lambda expressions
> already in the draft:

Yes. If I understand lambda expressions correctly, there are even some
in XPath 1.0 (i.e. predicates, steps in path expressions).

> 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:

Yes.

> It's not necessary for lambdas to be full data types in order to
> have a lexical representation.

No, but I think it is helpful for commonly used full data types to
have a consistent lexical representation. For example, if you have:

  1 + 1

you kinda have a right to expect that you can do:

  my:plus(1, 1)

rather than having to do:

  my:plus( number('1'), number('1') )

In other words, we should be careful, since lambda expressions are
being introduced to XPath now, to consider the fact that they might
become full data types in the future. We should take care that what we
do now does not make their adoption as a full data type in the future
impossible/difficult/messy.

> 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.

Perhaps you could expand on this a bit. It would be a good use case
for the note Dimitre's hopefully going to put together.

> 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).

Yes, I think it is. This is similar to the problem currently being
faced in what to do about constructors of simple typed values. If you
use a functional syntax:

  xs:date('2002-01-10')

then it implies that you can create the string dynamically, which
means that the processor can't statically check the string (or
something along those lines).

> Well, the conclusion in less convoluted form:
[snip]
> - 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.

Again, I think that expanding on this would be helpful.

> - Hiding lambda-like semantics in other definitions is not what i
>   would like.

What constitutes 'hiding'? Are you referring to my suggestion of
'pretending' that we're not introducing lambda expressions when we are
(in order to keep the XQuery people quiet) or the fact that various
expressions in the XPath 2.0 WD introduce lambda expressions without
being explicit about it?

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


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