cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Oliver <res1c...@verizon.net>
Subject Re: The granularity of continuations
Date Sun, 28 Sep 2003 18:53:52 GMT
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
>



Mime
View raw message