Re: Reference and First-Class Function

> >>>>> ...
> >>>>> the fact that HOF have been implemented *without* extensions long a=
go),
> >>>>>=A0 =

> >>>> 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 implementi=
ng =

> >> 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 goi=
ng to =

> have both we should implement one in terms of the other.
> >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^^
> > =

> > The "should" is absolutely unjustified here. We "could", but also we co=
uld =

> 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 sma=
ller =

> set of new features could be implemented in reasonable time and with reas=
onable =

> effort.
> =

> I don't think that you can brush off the argument that easily. There's pl=
enty to =

> justify implementing references in terms of HOF, including specification =

> coherency and reduced redundancy.

This might be the case. Then a developer *may* choose to provide such an im=
plementation. Or he may have his own opinion and choose another way of impl=
ementation. In the latter case, if we have limited his freedom of choice by=
 overspecifying, a developer may decide not to implement at all.

Regardless of our own preferences we must not force a developer into a sing=
le "best" option without alternatives. You may be in a position to do this =
in your oun company, often in an administrative way, but you cannot do this=
, hopefully, =A0with the outside world.

Overspecification is harmful -- should this fact be repeated again?

Imagine trying to buy a book A=A0 for $30 and the bookshop assistant tellin=
g you that you can only buy book A if you already have bought book B (for a=
nother $30).=A0 Will this work? Will you buy both books or will you go to a=
nother bookshop? Is the business practice of the first bookshop profitable?=
 Does it serve the goals of its customers?

> =

> 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 impl=
ement =

> both, reference objects and function objects have to be the same type - w=
hich =

> 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 *withou=
t* =

> >> 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 functio=
ns for =

> each HOF.
> >> =

> >> 2) Lambda (anonymous) functions.
> >> =

> >> 3) Closures and partial application - FXSL can't handle these complete=
ly.
> >> =

> >> 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 ob=
ject 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 f=
ar. He =

> has indicated that it is more realistic to define the "function" type jus=
t 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 spec=
ific =

> implementation.

And so will every other developer. Nobody wants added complexity. Nobody ne=
eds "big-bang" revolutionary changes that require significant time and effo=
rt=A0for something much simpler that we could obviously do immediately.

This is the spirit of EXSLT as compared to W3C.

To repeat again: Fundamental changes to the XPath/XSLT architecture such as=
 introducing a "function" type belong to the scope of W3C, not to EXSLT. At=
tempting to specify such fundamental new type not at W3C and just=A0as a se=
t of extensions, results in an incomplete and crippled specification that m=
ay adversely influence any work on a more comprehensive specification.

This may also indicate that the author is not sure that the spec will pass=
=A0the more strict technical=A0QA requirements of W3C and has more chances =
to be accepted by a less scrutinising mechanism elsewhere.


=A0
> > 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:evaluat=
e(), =

> exsl:document() and exsl:node-set(), which all pushed XSLT in a very diff=
erent =

> direction to the one the designers of XSLT had envisioned.

This is rather incorrect. The xx:node-set() existed in different implementa=
tions well before EXSLT summarized these de-facto existing implementations.=
=A0Similarly, exsl:document() was not such a revolutionary change, as compa=
red to dyn:evaluate().

On the other side, dyn:evaluate() *is* a revolutionary change and probably =
this is the main reason it is still not included in an existing W3C specifi=
cation.

This simply confirms the fact that revolutionary changes proposed by EXSLT =
(such as dyn:evaluate() ) fail to influence the official W3C specifications=
 even after considerable (4-5 years) time.

Here in EXSLT let us concentrate on the more simple and well-thought featur=
es, leaving more complex and "revolutionary" ones to the attention of the r=
espected W3C WGs, where they do belong.

Let us not bind one feature with the mandatory implementation of another fe=
ature.

Let's give the developers the freedom to choose and decide for themselves.


Cheers,

Dimitre



      =