Re: Reference and First-Class Function

Dimitre Novatchev wrote:
>>>>> ...
>>>>> the fact that HOF have been implemented *without* extensions long ago),
>>>>>   
>>>> This is quite true for XSLT, but not for XPath or (perhaps more importantly) 
>> XQuery.
>>> As I said, it is OK for anyone to propose extensions for HOFs (or for anything 
>> else).
>>> What is incorrect is to assume HOFs are a precondition for implementing 
>> references.
>>
>> I'm not sure anyone is assuming that. I think the thought process goes:
>>
>> o Higher order function support would be good to have.
>> o Sequence references would be good to have.
>> o Since HOF closures look a lot like sequence references, if we're going to have 
>> both we should implement one in terms of the other.
>                 ^^^^^^
> 
> The "should" is absolutely unjustified here. We "could", but also we could also implement each one independently, or just only one of them at a time, thus reducing complexity significantly and making it more realistic that a smaller set of new features could be implemented in reasonable time and with reasonable effort.

I don't think that you can brush off the argument that easily. There's 
plenty to justify implementing references in terms of HOF, including 
specification coherency and reduced redundancy.

Specifying one in terms of the other will not reduce an implementation's 
ability to only implement one of them at a time. All it means is that if 
you implement both, reference objects and function objects have to be 
the same type - which makes a lot of sense.

>>> Anyone could propose to implement HOF via extensions (and it is up to them to 
>> defend
>>> such a proposal given the fact that HOF have been implemented *without* 
>> extensions long
>>> ago)
>> With respect to everything that you've achieved in FXSL, there's still a lot 
>> that could be improved on:
>>
>> 1) Syntactic support - not having to define a template and two functions for 
>> each HOF.
>>
>> 2) Lambda (anonymous) functions.
>>
>> 3) Closures and partial application - FXSL can't handle these completely.
>>
>> 4) Support in the type system - a prerequisite for good optimization.
> 
> 
> I am well aware of all these, thank you for reminding. However, the introduction of such a fundamental data type as a first class function object in the type system must be addressed by the next versions of XPath and XSLT rather than being more incompletely described in an extension spec. Dr. Kay is a person, who has rich expertise and I admire his realistic estimation so far. He has indicated that it is more realistic to define the "function" type just as "subtypes of xs:anyAtomic rather than being a third kind of item".

I think Michael has said that his reasons were mostly to do with his 
specific implementation.

> All of the four items above require fundamental changes to the type system and good syntactic support -- something which cannot realistically be achieved by a set of extensions without having to significantly alter the existing underlying XPath/XSLT architecture. It is a goal of EXSLT 2.0 of "completely preserving the current functional nature and underlying architecture of XSLT/XPath 2.0."  (http://www.fgeorges.org/exslt2-wiki/EXSLT_2.0)

I'm not belittling FXSL - I think it's an amazing achievement. I was 
just pointing out that despite FXSL there are many reasons to think 
about adding extensions to support HOF.

> The task of EXSLT is to be pragmatic and instead of charting grandiose plans to define and promote small, and where possible independent, new features that are easy to implement and can be used as soon as possible.

I think there's a place for both. After all, EXSLT introduced 
dyn:evaluate(), exsl:document() and exsl:node-set(), which all pushed 
XSLT in a very different direction to the one the designers of XSLT had 
envisioned.

John

-- 
John Snelson, Oracle Corporation            http://snelson.org.uk/john
Berkeley DB XML:            http://oracle.com/database/berkeley-db/xml
XQilla:                                  http://xqilla.sourceforge.net