Discussion:
Reference and First-Class Function
Florent Georges
16 years ago
Permalink
Hi,

I've written a few words about references and firs-class functions
on the wiki, based on previous discussions. Even if they do not
necessarily represent a consensus, I thought that would be a useful
way to support discussions:

http://www.fgeorges.org/exslt2-wiki/Reference
http://www.fgeorges.org/exslt2-wiki/First-Class_Function

And critics welcome.

Regards,
--
Florent Georges
http://www.fgeorges.org/
Vladimir Nesterovsky
16 years ago
Permalink
Post by Florent Georges
I've written a few words about references and firs-class functions
on the wiki, based on previous discussions. Even if they do not
necessarily represent a consensus, I thought that would be a useful
http://www.fgeorges.org/exslt2-wiki/Reference
http://www.fgeorges.org/exslt2-wiki/First-Class_Function
And critics welcome.
1. Don't you think that ex:call() is overloaded with meanings?

2. ex:call($function, $arg1, $arg2, ...) assumes variable number of
parameters.
An alternative is to define single call syntax:
ex:function(xs:QName('my:add'));
ex:call($function, $argument);
--
Vladimir Nesterovsky
http://www.nesterovsky-bros.com
Florent Georges
16 years ago
Permalink
Post by Vladimir Nesterovsky
1. Don't you think that ex:call() is overloaded with meanings?
Sorry, I don't understand exactly what you mean.
Post by Vladimir Nesterovsky
2. ex:call($function, $arg1, $arg2, ...) assumes variable number
of parameters.
Yes. I don't like that, but I haven't find any other way.
Post by Vladimir Nesterovsky
ex:function(xs:QName('my:add'));
ex:call($function, $argument);
But what if your function takes several parameters?

Regards,
--
Florent Georges
http://www.fgeorges.org/
Vladimir Nesterovsky
16 years ago
Permalink
...
Function object should be an atomic type,
otherwise how can you store it in a sequence?
--
Vladimir Nesterovsky
http://www.nesterovsky-bros.com
Michael Kay
16 years ago
Permalink
Function object should be an atomic type, otherwise how can
you store it in a sequence?
A sequence is a sequence of items; currently the items can be atomic values
or nodes; the proposal is to add a third kind of item. It would still be an
item, therefore it could still be part of a sequence.

Michael Kay
http://www.saxonica.com/
Vladimir Nesterovsky
16 years ago
Permalink
Post by Michael Kay
Function object should be an atomic type, otherwise how can
you store it in a sequence?
A sequence is a sequence of items; currently the items can be atomic
values
Post by Michael Kay
or nodes; the proposal is to add a third kind of item. It would still be
an
Post by Michael Kay
item, therefore it could still be part of a sequence.
The qualification probably does not change the meaning, however xslt spec
suggests to consider extension object as atomic value:

18.1.3 External Objects
An implementation may allow an extension function to return an object that
does not have any natural representation in the XDM data model, either as
an atomic value or as a node.
--
Vladimir Nesterovsky
http://www.nesterovsky-bros.com
Michael Kay
16 years ago
Permalink
Post by Vladimir Nesterovsky
The qualification probably does not change the meaning,
however xslt spec suggests to consider extension object as
18.1.3 External Objects
An implementation may allow an extension function to return
an object that does not have any natural representation in
the XDM data model, either as an atomic value or as a node.
I would have said it says exactly the opposite - the "external object" is
neither an atomic value or a node, it is something else: a third kind of
item.

But the text does go on to say, in effect, that the implementation can
extend the type system any way it likes to accommodate such values.

Michael Kay
http://www.saxonica.com/
Florent Georges
16 years ago
Permalink
Vladimir Nesterovsky wrote:

Hi,
Post by Vladimir Nesterovsky
18.1.3 External Objects
An implementation may allow an extension function to return an object
that does not have any natural representation in the XDM data model,
either as an atomic value or as a node.
That's maybe because of my bad English, but I would have said the
text you quoted says instead that "an extension function can return
an object that is neither an atomic type nor a node," which seems to
be exactly what we have here.

Did I misunderstand something?

Regards,
--
Florent Georges
http://www.fgeorges.org/
Dimitre Novatchev
16 years ago
Permalink
  I've written a few words about references and firs-class functions
on the wiki, based on previous discussions.  Even if they do not
necessarily represent a consensus, I thought that would be a useful
    http://www.fgeorges.org/exslt2-wiki/Reference
    http://www.fgeorges.org/exslt2-wiki/First-Class_Function
I find that relating the topic of  "reference" in XPath to the topic of "higher order functions" is both too general and round-about. Remember that the need for references originally arised from needing them in higher-order functions -- for currying. Now we are trying to implement "reference" by currying a function. This is a complete circle.

At the same time I have defined in a quite formal and specific way what a "reference" is (the Ref object) and how to implement it in a way that allows both a reference to be representable by a storable value and to have a strict discipline of creating "copies" of references that can be used independently. This definition also solves the "leakage" problem.

Read it here:

   http://lists.fourthought.com/pipermail/exslt/2008-December/001705.html


Another remark is about the following text in the Wiki:

"Implementations
FXSL implements first-class functions and provides several higher-order function. It is entirely written in standard XSLT 2.0.
Retrieved from "http://www.fgeorges.org/exslt2-wiki/First-Class_Function""

FXSL never implemented this even simply due to the fact that FXSL existed 6-7 years before this text was written.

In fact FXSL implements higher-order functions in a completely different way and does not resort to or implement any extension functions.

Finally, we don't need to re-invent HOF in XSLT and implement it in less portable ways while they have already been here for 6 years. Let's save the time of developers and allow them to concentrate on features that are not yet implemented.


Cheers,
Dimitre
Florent Georges
16 years ago
Permalink
Dimitre Novatchev wrote:

Hi Dimitre,
Post by Florent Georges
http://www.fgeorges.org/exslt2-wiki/Reference
http://www.fgeorges.org/exslt2-wiki/First-Class_Function
I find that relating the topic of "reference" in XPath to the topic
of "higher order functions" is both too general and round-about.
Remember that the need for references originally arised from needing
them in higher-order functions -- for currying. Now we are trying to
implement "reference" by currying a function. This is a complete
circle.
I don't think so. What is proposed is to return a new first-class
function to provide references. Not to curry an existing one.
http://lists.fourthought.com/pipermail/exslt/2008-December/001705.html
Sorry, I hadn't read that email yet at the time I wrote the above
pages. I am going to respond to this email.
"Implementations
FXSL implements first-class functions and provides several
higher-order function. It is entirely written in standard XSLT 2.0.
Retrieved from
"http://www.fgeorges.org/exslt2-wiki/First-Class_Function""
FXSL never implemented this even simply due to the fact that FXSL
existed 6-7 years before this text was written.
Yes, sure. I say that it "implements first-class functions," not
this (not-ready-yet) extension. I can maybe make that more explicit.
Finally, we don't need to re-invent HOF in XSLT and implement it in
less portable ways while they have already been here for 6 years.
Let's save the time of developers and allow them to concentrate on
features that are not yet implemented.
Well, I really like FXSL, but I think the problem with currying is
precisely because it uses only standard XSLT. Being portable is of
course very important, but I do think that HOF could benefit from
having dedicated first-class function objects.

Regards,
--
Florent Georges
http://www.fgeorges.org/
Vladimir Nesterovsky
16 years ago
Permalink
...
Must be you're right.

I think, however, that that sentence is not perfect, as it may be treated
differently.

At first reading I've thought that "either as an atomic value or as a node"
relates to the "object".

"An implementation may allow an extension function to return an object
...
either as an atomic value or as a node."
--
Vladimir Nesterovsky
http://www.nesterovsky-bros.com
Vladimir Nesterovsky
16 years ago
Permalink
Post by Florent Georges
Post by Vladimir Nesterovsky
1. Don't you think that ex:call() is overloaded with meanings?
Sorry, I don't understand exactly what you mean.
1. ex:call() dereferences a reference.
2. ex:call() performs a function call.
Post by Florent Georges
Post by Vladimir Nesterovsky
2. ex:call($function, $arg1, $arg2, ...) assumes variable number
of parameters.
Yes. I don't like that, but I haven't find any other way.
Post by Vladimir Nesterovsky
ex:function(xs:QName('my:add'));
ex:call($function, $argument);
But what if your function takes several parameters?
In principle it's enough to support one argument function, taking into
account that
$argument can be a reference. That one argument function can forward a call
to a real
destination. In fact a pair ($function, $argument) can be thought as a
function-object.
--
Vladimir Nesterovsky
http://www.nesterovsky-bros.com
Vladimir Nesterovsky
16 years ago
Permalink
...
In fact $function can be just xs:QName.
The pair ($function, $argument) allows to model curry functions,
while types of $function, and $argument can be serialized in some way.
--
Vladimir Nesterovsky
http://www.nesterovsky-bros.com
Michael Kay
16 years ago
Permalink
It seems to me that even if it's syntactic sugar, allowing people to write

call($function, 1, 2, 3)

is a lot more usable than requiring them to write

call(curry(curry(curry($function, 1), 2), 3))

or even

call($function, (ref(1), ref(2), ref(3)))

Michael Kay
http://www.saxonica.com/
...
Dimitre Novatchev
16 years ago
Permalink
  I don't think so.  What is proposed is to return a new first-class
 function to provide references.  Not to curry an existing one.
And this is called overspecification.

It is not at all necessary to use higher order functions in order to implement references.

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), but it is incorrect to present HOF as a precondition for the capability to implement references.

A good specification should leave significant freedom to the implementor and not bind them to a particular implementation.
 
Cheers,
Dimitre
Micah Dubinko
16 years ago
Permalink
Post by Dimitre Novatchev
...
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.


Which is one of the reasons I'm following this discussion. :-)

Thanks, -m
Dimitre Novatchev
16 years ago
Permalink
Post by Dimitre Novatchev
...
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.

Thanks,
Dimitre
John Snelson
16 years ago
Permalink
Post by Dimitre Novatchev
Post by Dimitre Novatchev
...
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.
Post by Dimitre Novatchev
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.

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
Vladimir Nesterovsky
16 years ago
Permalink
Post by John Snelson
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.
I think it's rather untrivial to implement refereneces in terms
of higher order functions through extension functions and extension objects
only.

If there were inline functions that would be a copletely different thing.

If I'm wrong, can you please show an example of an expression using such
extensions.
--
Vladimir Nesterovsky
http://www.nesterovsky-bros.com
Dimitre Novatchev
16 years ago
Permalink
Sent: Friday, December 19, 2008 5:27:21 AM
Subject: Re: [exslt] Reference and First-Class Function
Post by John Snelson
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.
I think it's rather untrivial to implement refereneces in terms
of higher order functions through extension functions and extension objects
only.
+ 1

Completely agree with that! Asking to implement HOFs as a prerequisite of implementing references results in a much more complicated and difficult to implemented specification.

References can be implemented without needing an implementation of HOFs. This is much more simple, requires less effort and is therefore more realistic.

See my answer to John Snelson on this topic at:
http://lists.fourthought.com/pipermail/exslt/2008-December/001759.html


Cheers,
Dimitre
John Snelson
16 years ago
Permalink
...
Here's how I'd declare it in XQuery without using inline functions:

declare function ex:identity($x)
{
$x
};

declare function ex:ref($x)
{
ex:partial-apply(ex:function("ex:identity", 1), $x)
};

declare function ex:deref($r)
{
ex:call($r)
};

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
Vladimir Nesterovsky
16 years ago
Permalink
John,

I've read you proposal. It looks consistent.
Rather lengthy to my taste.
I would remove everything except function
types and inline functions, and titled proposal "... XPath".

I would possibly added typedefs to shorten type names.

In fact I would be satisfied if such feature found its way to the next spec.

The question is to WG people (Michael Kay?): shall we see something like
this in spec?

P.S. I know only one other WG that is more thorough in their work: C++ WG.
--
Vladimir Nesterovsky
http://www.nesterovsky-bros.com
...
John Snelson
16 years ago
Permalink
...
Here's how I'd declare it in XQuery without using inline functions:

declare function ex:identity($x)
{
$x
};

declare function ex:ref($x)
{
ex:partial-apply(ex:function("ex:identity", 1), $x)
};

declare function ex:deref($r)
{
ex:call($r)
};

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
Dimitre Novatchev
16 years ago
Permalink
...
                ^^^^^^

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

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)

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.

Dimitre
John Snelson
16 years ago
Permalink
...
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.
...
I think Michael has said that his reasons were mostly to do with his
specific implementation.
Post by Dimitre Novatchev
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.
Post by Dimitre Novatchev
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
Dimitre Novatchev
16 years ago
Permalink
...
This might be the case. Then a developer *may* choose to provide such an implementation. Or he may have his own opinion and choose another way of implementation. 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 single "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,  with the outside world.

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

Imagine trying to buy a book A  for $30 and the bookshop assistant telling you that you can only buy book A if you already have bought book B (for another $30).  Will this work? Will you buy both books or will you go to another bookshop? Is the business practice of the first bookshop profitable? Does it serve the goals of its customers?
...
And so will every other developer. Nobody wants added complexity. Nobody needs "big-bang" revolutionary changes that require significant time and effort for 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. Attempting to specify such fundamental new type not at W3C and just as a set of extensions, results in an incomplete and crippled specification that may adversely influence any work on a more comprehensive specification.

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


 
Post by Micah Dubinko
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.
This is rather incorrect. The xx:node-set() existed in different implementations well before EXSLT summarized these de-facto existing implementations. Similarly, exsl:document() was not such a revolutionary change, as compared 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 specification.

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 features, leaving more complex and "revolutionary" ones to the attention of the respected W3C WGs, where they do belong.

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

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


Cheers,

Dimitre
Michael Kay
16 years ago
Permalink
Post by Dimitre Novatchev
Regardless of our own preferences we must not force a
developer into a single "best" option without alternatives.
...
Post by Dimitre Novatchev
Overspecification is harmful -- should this fact be repeated again?
When you're designing a language I think it's important to minimize the set
of fundamental concepts, that is, concepts that can't be defined in terms of
other concepts. Good architectural layering is the essence of good software
specification and design. One of the main reasons for introducing HOF into
the foundations is that it allows many other things to be layered on top,
including such things as references, nested sequences, dictionaries, etc,
with less effort and complexity than if they were defined as primitives.
This is not overspecification: it's simply good architecture. And it's not
constraining implementors, either; the fact that we've layered the
specification in a particular way doesn't force implementors to layer their
implementations in the same way.

Michael Kay
http://www.saxonica.com/
Dimitre Novatchev
16 years ago
Permalink
Post by Michael Kay
One of the main reasons for introducing HOF into
the foundations is that it allows many other things to be layered on top,
including such things as references, nested sequences, dictionaries, etc,
with less effort and complexity than if they were defined as primitives.
The description so far that I have seen of implementing a reference with a HOF is the following:

     "A partial application or a closure will be used to implement a reference.

     The argument that is stored within the closure, and that must be produced as result, is the reference."

This is a circular definition -- a reference is supposed to be implemented by something that relies on reference itself. 

So in this case the concept of reference is not layered on top of the concept of HOF.
Michael Kay
16 years ago
Permalink
Post by Dimitre Novatchev
This is a circular definition -- a reference is supposed to be implemented
by something that relies on reference itself.
Post by Dimitre Novatchev
So in this case the concept of reference is not layered on
top of the concept of HOF.
No, it's not circular. If you have function closures, you get references for
free.

If I can create functions dynamically:

let $x := (<a>abcd</a>, <b>pqrs</b>)
let $ref := new function()->node() {$x}

Then $ref is for all practical purposes a reference to the node-sequence $x.
I can wrap this in some syntactic sugar to create functions ref() and
deref(), but I don't need to add any more concepts. There is no conceptual
difference between a reference to a value and a zero-argument function whose
result is that value: and we shouldn't invent two new concepts if one of
them entirely subsumes the other.

Michael Kay
http://www.saxonica.com/
Dimitre Novatchev
16 years ago
Permalink
Re: [exslt] Reference and First-Class Function
...
No, what is buried inside the definition of $ref above is not a "value". If it is not a "copy" of $x it is a *reference* to $x.
  let $ref := new function()->node() {$x}
already contains a reference to $x.

You may pretend this is not a reference, but this doesn't change the fact.

When the concepts of partial application and closures were first created, this was done in a context in which references were already there and nobody could even imagine they could not use references.

The available definitions for closure (see for example: http://en.wikipedia.org/wiki/Closure_(computer_science)) confirm this.

To quote from that source:

"
In this example, the lambda expression (lambda (book) (>= (book-sales book) threshold)) appears within the function best-selling-books. When the lambda expression is evaluated, Scheme creates a closure consisting of the code for the lambda and a reference to the threshold variable, which is a free variable inside the lambda.
"

So, "a closure consisting of the code for the lambda and a reference to the threshold variable".

A little bit downwards:

"Because the closure in this case outlives the scope of the function that creates it, the variables f and dx live on after the function derivative returns. In languages without closures, the lifetime of a local variable coincides with the execution of the scope where that variable is declared. In languages with closures, variables must continue to exist as long as any existing closures have references to them. This is most commonly implemented using some form of garbage collection"

So, "In languages with closures, variables must continue to exist as long as any existing closures have references to them."

Once again, closures "have references" to external variables.

As I said even in my previous message, a closure contains a reference. A closure relies on the concept of reference being already implemented.


Dimitre
Florent Georges
16 years ago
Permalink
Post by Dimitre Novatchev
Once again, closures "have references" to external variables.
As I said even in my previous message, a closure contains a
reference.
Or put in another way: if you get closures, you get references.
Post by Dimitre Novatchev
A closure relies on the concept of reference being already
implemented.
I wouldn't put it like that. Closures does not rely on the feature
of reference being available in the language, even if their
implementation needs to provide that in some way.

And as Michael showed us, if you get closures, you get references for
free.

Regards,
--
Florent Georges
http://www.fgeorges.org/
Dimitre Novatchev
16 years ago
Permalink
Post by Dimitre Novatchev
Once again, closures "have references" to external variables.
As I said even in my previous message, a closure contains a
reference.
  Or put in another way: if you get closures, you get references.
This statement ignores the fact that the term "reference" is used in the definition of "closure" I quoted the definition of closure from Wikipedia and the places where the term "reference" is used.
Post by Dimitre Novatchev
A closure relies on the concept of reference being already
implemented.
  I wouldn't put it like that.  Closures does not rely on the feature
of reference being available in the language, even if their
implementation needs to provide that in some way.
A very interesting statement... :)  So, we confess of having to use references  ...  from somewhere...???

Then we deny references existed when we used them...

Then we say: We give you references *for free* !

This made my day, Thank you.
  And as Michael showed us, if you get closures, you get references for
free.
Of course -- as you already have *references* inside the closure!

Dr. Kay did't show anything. He expressed his believes on the topic.

On the other side, I provided quotes to the definition of closure. This is not my belief, but the oficial definition.

The definition of closure uses references, so it is not what Dr. Kay is speaking about.

Therefore, it would be correct if Dr. Kay stops calling "closure" the thing he is talking about, rename it to something else, and most importantly, show how this "something else" can create a reference out of thin air.


Cheers,
Dimitre
Vladimir Nesterovsky
16 years ago
Permalink
Dimitre,

You may approach to this problem from two different perspectives:

1. Postulate existance of function closures,
and derive references from closures.
2. Postulate existance of references and indirect function calls,
and derive closures from these constructs.

If there were inline functions I would prefer 1.
If I had to model these features through extension functions
and extension objects only, I would use 2.

--
Vladimir Nesterovsky
http://www.nesterovsky-bros.com
Post by Florent Georges
Post by Dimitre Novatchev
Once again, closures "have references" to external variables.
As I said even in my previous message, a closure contains a
reference.
Or put in another way: if you get closures, you get references.
This statement ignores the fact that the term "reference" is used in the
definition of "closure" I quoted the definition of closure from Wikipedia
and the places where the term "reference" is used.
Post by Florent Georges
Post by Dimitre Novatchev
A closure relies on the concept of reference being already
implemented.
I wouldn't put it like that. Closures does not rely on the feature
of reference being available in the language, even if their
implementation needs to provide that in some way.
A very interesting statement... :) So, we confess of having to use
references ... from somewhere...???

Then we deny references existed when we used them...

Then we say: We give you references *for free* !

This made my day, Thank you.
Post by Florent Georges
And as Michael showed us, if you get closures, you get references for
free.
Of course -- as you already have *references* inside the closure!

Dr. Kay did't show anything. He expressed his believes on the topic.

On the other side, I provided quotes to the definition of closure. This is
not my belief, but the oficial definition.

The definition of closure uses references, so it is not what Dr. Kay is
speaking about.

Therefore, it would be correct if Dr. Kay stops calling "closure" the thing
he is talking about, rename it to something else, and most importantly, show
how this "something else" can create a reference out of thin air.
Dimitre Novatchev
16 years ago
Permalink
Post by Florent Georges
Dimitre,
 .............................
Post by Florent Georges
2. Postulate existance of references and indirect function calls,
  and derive closures from these constructs.
Vladimir,

There is no need to "postulate" the existence of references as they already exist (in all programming languages I am aware of). Do you need to postulate that "water exists"?

We really have and use references in XPath, XSLT and I believe XQuery as a superset of XPath.Any

   <xsl:sequence select="someNode"/>

instruction produces a reference to that node, not a copy of it.

We have many statements from Dr. Kay himself, one of the most recent is probably from this September in the thread in xsl-list "Benefits of xsl.sequence" :

http://www.stylusstudio.com/xsllist/200809/post50470.html

"Yes: this is the only way that you can write a function (or indeed a
template) that returns references to existing nodes"


And there are quite some of his statements to this effect through the years (the earliest I have seems to be from 2003).

Another source of statements that we have been using references all the time in XSLT 2.0 are the books of Dr. Kay.

To quote Dr. Kay's book "XSLT 2.0 and XPath 2.0  4th edition Programmer's Reference",  ISBN: 978-0-470-19274-0, page 452:

"The <xsl:sequence> instruction ... is the only XSLT instruction (with the exception of <xsl:perform-sort>) that can return references to existing nodes, as distinct from newly constructed nodes."

Identical text is on page 420 of Dr. Kay's book "XSLT 2.0 3rd edition Programmer's Reference" (ISBN: 0-764-56909-0)

So, references do exist in XPath and XSLT, they are held in a variables and returned from functions. The only problem is whenever we want to store them in an XML document or use a reference to a sequence as an atomic item inside another sequence.

There is no problem of defining a "reference" type without closures and the whole attempt to invent references through closures is incorrect and artificial. References were there all the way, we were happily using them without ever complaining that they lacked closures. 

References exist and are used in most XSLT 2.0 transformations. We don't need to postulate anything -- just use what we already have in a more formal definition of the "reference" type.


The issue I have raised is that any attempt to define references based on closures ignores the fact that closures are defined using references -- this is a circular definition and it expands infinitely (like infinite recursion) and fails to define anything.
Post by Florent Georges
The definition of closure uses references, so it is not what Dr. Kay is speaking
about.
Therefore, it would be correct if Dr. Kay stops calling "closure" the thing he
is talking about, rename it to something else, and most importantly, show how
this "something else" can create a reference out of thin air.
Cheers,
Dimitre
...
Vladimir Nesterovsky
16 years ago
Permalink
Dimitre,
So, references do exist in XPath and XSLT, they are held in a
variables and returned from functions. The only problem is
whenever we want to store them in an XML document or use a
reference to a sequence as an atomic item inside another sequence.
An atomic item referencing a sequence inside another sequence
does not exist in the current specs.

I suspect we tacitly call such item as a reference.

What is the type of such item?

It can be proposed type (function() as item()*) - argumentless function
returning a sequence,
or some other type, encapsulating a sequence.

Both approaches allow to define single API ref(), deref().
Thus the question, in fact, belongs to implementation details.

If inline functions existed how would you implement ref(), deref()?

On the other hand I do not like the idea of ex:partial-apply(), as it's
defined in John's proposal, as it resembles reflection very much.

In absence of inline functions I'd based implementation of references (and
maps) on external objects.

P.S. If there were typedefs one could conceal the difference even more.
--
Vladimir Nesterovsky
http://www.nesterovsky-bros.com
Vladimir Nesterovsky
16 years ago
Permalink
Post by Vladimir Nesterovsky
An atomic item referencing a sequence inside another sequence
does not exist in the current specs.
Again my poor wording...

An atomic item stored inside of another sequence and referencing a sequence,
does not exist in current specs.
Post by Vladimir Nesterovsky
So, references do exist in XPath and XSLT, they are held in a
variables and returned from functions. The only problem is
whenever we want to store them in an XML document or use a
reference to a sequence as an atomic item inside another sequence.
An atomic item referencing a sequence inside another sequence
does not exist in the current specs.
Dimitre Novatchev
16 years ago
Permalink
Vladimir,
Post by Vladimir Nesterovsky
So, references do exist in XPath and XSLT, they are held in a
variables and returned from functions. The only problem is
whenever we want to store them in an XML document or use a
reference to a sequence as an atomic item inside another sequence.
An atomic item referencing a sequence inside another sequence
does not exist in the current specs.
Neither does a reference to a node. However both  are actualy used in any XSLT transformation.

Whenever an argument to a function is a sequence, what is actually passed to the function is a reference to that sequence (the sequence is not copied).

References, either to nodes or to sequences, do exist in XSLT and everybody uses them.
Post by Vladimir Nesterovsky
On the other hand I do not like the idea of ex:partial-apply(), as it's
defined in John's proposal, as it resembles reflection very much.
EXSLT is not a place to comment on such a proposal -- its proper destination is W3C. Therefore I will not comment on it.
Post by Vladimir Nesterovsky
In absence of inline functions I'd based implementation of references (and maps)
on external objects.
Yes, I think this is a sound and logical way to go.

 
Cheers,
Dimitre
Michael Kay
16 years ago
Permalink
Post by Dimitre Novatchev
Whenever an argument to a function is a sequence, what is
actually passed to the function is a reference to that
sequence (the sequence is not copied).
How would you be able to detect the difference?
Post by Dimitre Novatchev
References, either to nodes or to sequences, do exist in XSLT
and everybody uses them.
This is a bit like saying that mutable storage exists in XSLT because all
known implementations use it internally. It's confusing what's present in
the language semantics with what might be present in the internals of an
implementation.

Michael Kay
http://www.saxonica.com/
Dimitre Novatchev
16 years ago
Permalink
Post by Michael Kay
Post by Dimitre Novatchev
References, either to nodes or to sequences, do exist in XSLT and everybody uses them.
This is a bit like saying that mutable storage exists in XSLT because all
known implementations use it internally. It's confusing what's present in
the language semantics with what might be present in the internals of an
implementation.
Could be like this, were it not for the excellent books that explain how references to nodes are returned by <xsl:sequence>.


Cheers,
Dimitre
Florent Georges
16 years ago
Permalink
Post by Dimitre Novatchev
  I wouldn't put it like that.  Closures does not rely on the feature
of reference being available in the language, even if their
implementation needs to provide that in some way.
A very interesting statement... :)  So, we confess of having to use
references  ...  from somewhere...???
Then we deny references existed when we used them...
No. The definition uses the word "reference" to define the behavior
of the feature. The implementation thus has to use something (in the
implementation language, black magic or whatever) to behave as stated.
But that does not mean a similar feature has to have been defined
anywhere to be used by the user.

Or I have missed something.

Regards,
--
Florent Georges
http://www.fgeorges.org/
Vladimir Nesterovsky
16 years ago
Permalink
Hello,

I think we can introduce "Reference and First-Class Functions" in the
exslt's way through something, which is very close to that defined in Saxon:
saxon:expression() and saxon:evaluate().

See
http://www.saxonica.com/documentation/extensions/functions/expression.html

The only difference is that saxon:expression() should be evaluated with
dynamic context based on that of declaration place and with defined
variables $p1, $p2, ...
--
Vladimir Nesterovsky
http://www.nesterovsky-bros.com/

Loading...