You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2003/09/28 18:27:29 UTC
The granularity of continuations
Hi all,
Investingating in the fancy uses that can be made of continuations, I
was reading again the RhinoWithContinuations page on the wiki [1], and I
felt confused by an example in that page :
function someFunction() {
var kont = new Continuation();
print("captured: " + kont);
return kont;
}
var k = someFunction();
if (k instanceof Continuation) {
print("k is a continuation");
k(200);
} else {
print("k is now a " + typeof(k));
}
print(k);
Whose result is :
captured: [object Continuation]
k is a continuation
k is now a number
200
Why is "captured: [...]" printed only once, even if located _after_ the
"new Continuation()" statement which I supposed to take the snapshot of
the current execution state ?
The anwser is (Chris, please confirm or correct me if this is wrong)
that "new Continuation()" doesn't take a snapshot of the exact location
of the statement, but a snapshot of the closest function call, i.e.
"someFunction()" in that case. And when the continuation is called using
"k(200)", execution restarts at the location where someFunction() was
called, with the new "200" result. Thus why we don't see "captured:
[...]" twice.
So the granularity of a continuation is the _function call_, and not the
statement.
Consider now this :
function someFunction() {
var kont1 = new Continuation();
print("captured 1");
var kont2 = new Continuation();
print("captured 2");
return kont1; // or kont2 !!
}
Returning kont1 or kont2 doesn't matter, as the execution will restart
at the call point of someFunction(). Confusing...
Digging further on continuations, I found an interesting comment to a
weblog [2], where the guy proposes to extend the "arguments" object to
hold the continuation associated to a function, i.e. replace :
var kont = new Continuation();
by :
var kont = arguments.continuation;
IMO, this syntax removes the confusion outlined above, since it
unambiguously attaches the continuation to the current function call,
and thus matches better the actual granularity of a continuation.
What do you think ? Would it be difficult to implement it that way ?
Sylvain
[1] http://wiki.cocoondev.org/Wiki.jsp?page=RhinoWithContinuations
[2] http://lambda.weblogs.com/discuss/msgReader$8089#8093
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: The granularity of continuations
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Christopher Oliver wrote:
> Sylvain,
>
> I had previously seen that post on lambda-the-ultimate, and I liked
> the arguments.continuation idea. However, it seemed rather low
> priority (at least for me). Your posts prompted me to implement it
> (which turned out to be very easy). I don't think we have
> communication problems, rather I think we have had some disagreements.
> But in this case we do agree.
Ah, ok. So everything is fine. But you see, these simple words would
have avoided me to wonder about your feelings ;-)
Thanks,
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: The granularity of continuations
Posted by Christopher Oliver <re...@verizon.net>.
Sylvain,
I had previously seen that post on lambda-the-ultimate, and I liked the
arguments.continuation idea. However, it seemed rather low priority (at
least for me). Your posts prompted me to implement it (which turned out
to be very easy). I don't think we have communication problems, rather I
think we have had some disagreements. But in this case we do agree.
Regards,
Chris
Sylvain Wallez wrote:
> Christopher Oliver wrote:
>
>> Ok, ok. I've checked in an implemention of arguments.continuation
>> into the Rhino cvs on cocoondev.org. Please test it and let me know
>> if it's ok. If so, someone can go ahead and update the cocoon cvs.
>
>
>
> Chris, I don't know what's your state of mind about this (we already
> had communication problems in the past), but I'd like to make it clear
> that I don't want to impose anything. I simply had problems
> understanding the real behaviour of continuations, and this "new
> Continuation()" was part of these problems. I would have been happier
> with some agreement from you, rather than a simple "ok, ok" that makes
> me think you were bored by my remarks.
>
> I also would like some feedback from other non-Schemers around there
> to know their feelings about this. Or am I the only one that digged so
> deep in the flowscript internals ?
>
> Sylvain
>
Re: The granularity of continuations
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
mratliff@collegenet.com wrote:
> Sylvain,
>
> Speaking as someone who understands continuations about as well as
> they do Attic Greek (menin aedie Thea is about as far as I have
> gotten), I appreciated the publication of your investigations. I
> understand continuations a bit better now. Thank you.
Thanks. I plan to start some docs with practical information about
continuations: kind of "continuations for dummies" with uses cases,
examples and best practices. Hopefully, this will help people getting
started with this amazing feature.
But this will be after the GetTogether, as I have a lot to do before,
including finishing my presentation.
Sylvain
PS: I understand your feeling about antic Greek, as I never learned a
single word of it ;-)
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: The granularity of continuations
Posted by mr...@collegenet.com.
Sylvain,
Speaking as someone who understands continuations about as well as they do
Attic Greek (menin aedie Thea is about as far as I have gotten), I
appreciated the publication of your investigations. I understand
continuations a bit better now. Thank you.
--Michael
Sylvain Wallez <sy...@anyware-tech.com> wrote on 09/28/2003
11:36:00 PM:
> Christopher Oliver wrote:
>
> > Ok, ok. I've checked in an implemention of arguments.continuation into
> > the Rhino cvs on cocoondev.org. Please test it and let me know if
> > it's ok. If so, someone can go ahead and update the cocoon cvs.
>
>
> Chris, I don't know what's your state of mind about this (we already had
> communication problems in the past), but I'd like to make it clear that
> I don't want to impose anything. I simply had problems understanding the
> real behaviour of continuations, and this "new Continuation()" was part
> of these problems. I would have been happier with some agreement from
> you, rather than a simple "ok, ok" that makes me think you were bored by
> my remarks.
>
> I also would like some feedback from other non-Schemers around there to
> know their feelings about this. Or am I the only one that digged so deep
> in the flowscript internals ?
>
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://www.apache.org/~sylvain http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
> Orixo, the opensource XML business alliance - http://www.orixo.com
>
>
Re: The granularity of continuations
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Christopher Oliver wrote:
> Ok, ok. I've checked in an implemention of arguments.continuation into
> the Rhino cvs on cocoondev.org. Please test it and let me know if
> it's ok. If so, someone can go ahead and update the cocoon cvs.
Chris, I don't know what's your state of mind about this (we already had
communication problems in the past), but I'd like to make it clear that
I don't want to impose anything. I simply had problems understanding the
real behaviour of continuations, and this "new Continuation()" was part
of these problems. I would have been happier with some agreement from
you, rather than a simple "ok, ok" that makes me think you were bored by
my remarks.
I also would like some feedback from other non-Schemers around there to
know their feelings about this. Or am I the only one that digged so deep
in the flowscript internals ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: The granularity of continuations
Posted by Christopher Oliver <re...@verizon.net>.
Ok, ok. I've checked in an implemention of arguments.continuation into
the Rhino cvs on cocoondev.org. Please test it and let me know if it's
ok. If so, someone can go ahead and update the cocoon cvs.
Regards,
Chris
Sylvain Wallez wrote:
> Sylvain Wallez wrote:
>
> <snip/>
>
>> Now back to the syntactic problem. I digged a bit and found the
>> definition of the Scheme continuation at [1]. And although Rhino's
>> continuations may follow that of Scheme, I see no real possible
>> comparison between the respective syntaxes :
>> - Scheme's "call/cc" passes the continuation to its single parameter
>> which is a procedure and executes this procedure. And the
>> continuation (AFAIU) captures the state at its invocation point and
>> not the state of the enclosing function.
>> - Rhino's "new Continuation()" captures the continuation of the
>> enclosing function call and returns it, without further processing.
>
>
>
> Update: after thinking further, I understand how Rhino and Scheme
> syntaxes relate. Rhino's function in which "new Continuation()" is
> called is actually the equivalent to the argument of call/cc.
>
> But IMO this only enforces the fact that we don't *create* a
> continuation, but just *get* that of the enclosing function.
>
> Sylvain
>
Re: The granularity of continuations
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Sylvain Wallez wrote:
<snip/>
> Now back to the syntactic problem. I digged a bit and found the
> definition of the Scheme continuation at [1]. And although Rhino's
> continuations may follow that of Scheme, I see no real possible
> comparison between the respective syntaxes :
> - Scheme's "call/cc" passes the continuation to its single parameter
> which is a procedure and executes this procedure. And the continuation
> (AFAIU) captures the state at its invocation point and not the state
> of the enclosing function.
> - Rhino's "new Continuation()" captures the continuation of the
> enclosing function call and returns it, without further processing.
Update: after thinking further, I understand how Rhino and Scheme
syntaxes relate. Rhino's function in which "new Continuation()" is
called is actually the equivalent to the argument of call/cc.
But IMO this only enforces the fact that we don't *create* a
continuation, but just *get* that of the enclosing function.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: The granularity of continuations
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Christopher Oliver wrote:
> The code
>
> new Continuation()
>
> returns an object representing the continuation of the current
> function invocation. I don't see why that is confusing (if you
> understand the concept of continuations in the first place). The
> created object is itself a function. When you invoke it it causes that
> function invocation to return with the value you pass as an argument.
> This is the same behavior as in Scheme. I personally don't see a
> problem here...
First, thanks for confirming my understanding. Now there are several
interesting points in what you say. Warning, we enter a highly
subjective discussion.
You point out precisely the problem, but don't see its importance as you
enclose it with parenthesis : "if you understand the concept of
continuations in the first place". This is the key, as *most people
using Cocoon have never heard of Scheme nor of continuations*.
This means that most people (including myself, even if I did a
reasonable amount of Lisp 15 years ago) have hard times understanding
the details of exactly how continuations behave and what gets captured.
Sure, sendPageAndWait() provides a simple wrapper to use continuations
without knowing, but going further or even understanding that handling
of the back button depends on how variable declarations are intermingled
with continuations require a more precise understanding of what happens
under the hood. And having a syntax that encourages misunderstanding is
not good in this regard.
Now back to the syntactic problem. I digged a bit and found the
definition of the Scheme continuation at [1]. And although Rhino's
continuations may follow that of Scheme, I see no real possible
comparison between the respective syntaxes :
- Scheme's "call/cc" passes the continuation to its single parameter
which is a procedure and executes this procedure. And the continuation
(AFAIU) captures the state at its invocation point and not the state of
the enclosing function.
- Rhino's "new Continuation()" captures the continuation of the
enclosing function call and returns it, without further processing.
I have no problem with the fact that Rhino's approach doesn't have a
function as argument, and that it captures the enclosing function, but
I'm concerned by the mismatch caused by the fact that the implied
meaning of the continuation creation statement is so much decorrelated
from the function itself.
Consider the following :
function someFunction() {
var k1 = new Continuation();
var k2;
// nested control structure
for (var i = 0; i < 1; i++) {
k2 = new Continuation();
}
print("k1 == k2 is " + k1 == k2);
return k1; // or k2...
}
The result is "k1 == k2 is false", which seems good considering the code
from the procedural point of view, but *k1 and k2 are totally
equivalent*. Calling one or the other will lead to exactly the same
result. Isn't this confusing ? At least it confused me, and I guess many
others will be confused also.
That's what I'm proposing a different notation that unambiguously
relates the continuation with the function. And the
"arguments.continuation" notation seems good to me as "arguments"
relates to the current function call (just as "argument.callee" returns
the function itself).
Yeah, that's nitpicking, but I consider this important as continuations
are incredibly powerful, but not that easy to understand. This has
already been shown by numerous posts. And a clear syntax is IMO key to
its wide adoption.
Sylvain
[1] http://www.scheme.com/tspl2d/control.html#g1965
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
Re: The granularity of continuations
Posted by Christopher Oliver <re...@verizon.net>.
The code
new Continuation()
returns an object representing the continuation of the current function
invocation. I don't see why that is confusing (if you understand the
concept of continuations in the first place). The created object is
itself a function. When you invoke it it causes that function invocation
to return with the value you pass as an argument. This is the same
behavior as in Scheme. I personally don't see a problem here...
My $0.02,
Chris
Sylvain Wallez wrote:
> Hi all,
>
> Investingating in the fancy uses that can be made of continuations, I
> was reading again the RhinoWithContinuations page on the wiki [1], and
> I felt confused by an example in that page :
>
> function someFunction() {
> var kont = new Continuation();
> print("captured: " + kont);
> return kont;
> }
>
> var k = someFunction();
> if (k instanceof Continuation) {
> print("k is a continuation");
> k(200);
> } else {
> print("k is now a " + typeof(k));
> }
> print(k);
>
> Whose result is :
> captured: [object Continuation]
> k is a continuation
> k is now a number
> 200
>
> Why is "captured: [...]" printed only once, even if located _after_
> the "new Continuation()" statement which I supposed to take the
> snapshot of the current execution state ?
>
> The anwser is (Chris, please confirm or correct me if this is wrong)
> that "new Continuation()" doesn't take a snapshot of the exact
> location of the statement, but a snapshot of the closest function
> call, i.e. "someFunction()" in that case. And when the continuation is
> called using "k(200)", execution restarts at the location where
> someFunction() was called, with the new "200" result. Thus why we
> don't see "captured: [...]" twice.
>
> So the granularity of a continuation is the _function call_, and not
> the statement.
>
> Consider now this :
> function someFunction() {
> var kont1 = new Continuation();
> print("captured 1");
> var kont2 = new Continuation();
> print("captured 2");
> return kont1; // or kont2 !!
> }
> Returning kont1 or kont2 doesn't matter, as the execution will restart
> at the call point of someFunction(). Confusing...
>
> Digging further on continuations, I found an interesting comment to a
> weblog [2], where the guy proposes to extend the "arguments" object to
> hold the continuation associated to a function, i.e. replace :
> var kont = new Continuation();
> by :
> var kont = arguments.continuation;
>
> IMO, this syntax removes the confusion outlined above, since it
> unambiguously attaches the continuation to the current function call,
> and thus matches better the actual granularity of a continuation.
>
> What do you think ? Would it be difficult to implement it that way ?
>
> Sylvain
>
> [1] http://wiki.cocoondev.org/Wiki.jsp?page=RhinoWithContinuations
> [2] http://lambda.weblogs.com/discuss/msgReader$8089#8093
>