Re: Re: mapping (Was: Re: Re: . in for)

Joerg Pietschmann <joerg dot pietschmann at zkb dot ch> wrote:

> 3. Higher order functions. I'm walking on thin ice here but i
>  believe this requires the possibility to compose lambda expressions
>  from run-time supplied data. Toghether with a funcall() function, this
>  should be equivalent to the evaluate() function proposed elsewhere.

Wrong. An FP language does not generally require dynamic evaluate() function. Take
for example Haskell. It is a compiled language. Functions are compiled, not
interpreted at run time. Probably one can create an evaluate() function (and there
are Haskell interpreters written in Haskell), but this is not at all necessary in
order to create Haskell applications.

[snip]

> As for true higher order functions, i still can't come up with
> convincing use cases apart from evaluate(). 

Wrong again -- evaluate() is not necessary for an FP language.

> For lambda expressions as data types, well, the most obvious use
> case is presented just above. It would also allow Dimitre to
> reformulate most of his "generic template" stuff in a more compact
> and usable form.

Not "generic template stuff" but "FP stuff", and you haven't seen most of either of
these. And to say that the "FP stuff" is not usable means not to understand what FP
is.


> Until now, only
> Dimitre expresses some urgent need, and even he hasn't yet presented
> a convincing use case. 

Wrong -- for a third time. Dimitre doesn't express any urgent needs, especially to
convince anybody about anything.

Dimitre is happy to program in Haskell and then translate the Haskell solution into
XSLT 1.0, if that's necessary. The side effect is that a considerable library of
general functions has been implemented in XSLT 1.0 and it is immediately usable.

Cheers,
Dimitre Novatchev.




__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

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