Re: Scheme Continuations vs Brakes Continuations was Re: Groovy support in Cocoon

[Stephan Michels <st...@apache.org>]

Am Mo, den 05.04.2004 schrieb Christopher Oliver um 22:44:
> >Why don't use (Object obj, Method method, Object[] args) in the
> >constructor of the continuation object.
>
> That's a possible alternative, but makes prevents making Continuation an 
> abstract class.

Why should the continuation be abstract? The idea of the brakes people
was to create something similar to java.lang.Thread

Thread t = new Thread(new Runnable() {
  void run() {
    sendPage("a");
    wait();
    sendPage("b");
  }
}); 
t.start();


> >Continuation.SUICIDE.invoke(null); ?
> >
> >*you see many question marks over my head*
> >
> >I hope you have patience with me :)
> >
> >  
> >
> The idea of SUICIDE is that it has the effect of unwinding the stack but 
> not executing any further code and directly returns to the entry point 
> (i.e. it is the continuation of the end of some code ). For example (in JS):
> 
> var suicide;
> 
> function f() {
>    suicide = arguments.continuation;
> }
> 
> f();  // <== since there's no code to execute after f(), invoking 
> suicide later will have the effect of simply terminating the script.
> // end of script
> 
> 
> In the current Rhino implementation creating a Continuation in a 
> top-level script has the same effect (since what comes after the end of 
> the script is - nothing).
> 
> This behavior is as in Scheme.

Hmmm, not every intuitive. So your f() has the same role like
Continuation.suspend() ?

With call of suspend() the Continuation goes from the State "restoring"
into State "!restoring & !capturing", and in cases of the 
state "!restoring & !capturing" into the state "capturing".

Stephan.

Re: Scheme Continuations vs Brakes Continuations was Re: Groovy support in Cocoon

[Christopher Oliver <re...@verizon.net>]

Stephan Michels wrote:

>Am Mo, den 05.04.2004 schrieb Christopher Oliver um 22:44:
>  
>
>>>Why don't use (Object obj, Method method, Object[] args) in the
>>>constructor of the continuation object.
>>>      
>>>
>>That's a possible alternative, but makes prevents making Continuation an 
>>abstract class.
>>    
>>
>
>Why should the continuation be abstract? The idea of the brakes people
>was to create something similar to java.lang.Thread
>
>  
>
Primarily to hide the implementation details, but this is not a big issue.

> <snip>
>
>>This behavior is as in Scheme.
>>    
>>
>
>Hmmm, not every intuitive. So your f() has the same role like
>Continuation.suspend() ?
>
>  
>
Yes. Although it may seem unintuitive at first glance, there is a long 
and well-known history of continuations in Scheme. We should try to 
follow that model if possible, IMO.

BTW, I started playing around with BCEL and your code (mostly debugging 
VerifyErrors whenever I try to add anything... ;)). One serious problem 
I noticed is that we can never allow calls through reflection in the 
call chain that leads to creation of a continuation - because 
java.lang.reflect.Method.invoke() is not and cannot be instrumented. I 
know Rhino has the capability to generate "Invoker" classes at runtime 
to replace reflection calls with direct compiled calls 
(http://lxr.mozilla.org/mozilla/source/js/rhino/src/org/mozilla/javascript/Invoker.java). 
These "Invoker" classes _could_ be instrumented and therefore used in a 
continuation. However, some changes to Rhino would be required I think, 
because these classes are loaded by a Rhino-internal class loader so 
there's no opportunity to instrument them. I don't know if Groovy or 
Jython use reflection. If so, a similar approach to Rhino's "Invoker" 
could be used there also.

Regards,

Chris