cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: The granularity of continuations
Date Sun, 28 Sep 2003 20:46:53 GMT
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 Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message