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

[Christopher Oliver]

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