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
