cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Bukanov ...@igor.fastmail.fm>
Subject Re: Rhino from mozilla.org and continuations
Date Thu, 16 Sep 2004 23:45:43 GMT
Sylvain Wallez wrote:
> 
> A minor remark though, about the syntax for creating the continuation. 
> AFAICS, this is currently done with "Continuation()". I personally find 
> it misleading, as the continuation represents the point where the 
> current function was called, and not the point where the 
> "Continuation()" statement occured.
> 
> Long ago, I proposed to Chris to allow a syntax suggested in [1] (2nd 
> post) which is "arguments.continuation" which clearly relates the 
> continuation to the point where the function is called, and he 
> implemented it in [2] (search for "TokenStream.GETPROP").

Any use of "arguments" in Rhino is very expensive since it prevents fast 
access to variables in the function that uses that. In addition 
ECMAScript allows to alias arguments arbitrary or even to hide by local 
variable/parameter name so the way it is implemented in Cocoon version 
of Rhino just does not work. It is possible to do it properly but that 
would give code bloat.

IMO syntax is only nice if it allows a reasonable implementation without 
many corner cases. By that definition arguments.continuation is not nice 
while Continuation() is. Note if arguments would be a keyword in JS, the 
story would be opposite, but JS legacy takes its toll.

Plus function syntax allows to implement rather trivially optional 
arguments like amount of frames to capture. For example, suppose you 
want to define a function in JS that would behave exactly as 
Continuation() while adding a log about it. Then one could use something 
like:

function my_continuation()
{
     log();
     return Continuation(2);
}

And then Continuation(0) would capture exactly at the point of 
invocation with Continuation() defaulting to Continuation(1). Note that 
I do not propose that, but rather argue that function syntax has its 
advantages as well.

> 
> This may seem as nitpicking, but if this is to go into the official 
> Rhino and if Cocoon has to cope with minor incompatibilities like 
> catch(continue|break|return), it would be good to have a clean syntax 
> for continuations.
> 
> What do you think?

It is hard to implement catch(continue|break|return) correctly. For 
example, what should happen if an exception is thrown during the 
execution of code there or what if continuation is captured/restored 
inside the catch block? Depending on the situation the version in Cocoon 
would either throw an exception or go into infinite loop. AFAICS 
respecting "finally" has rather simple answers in all those corner cases 
and that is why I put efforts to implement it rather the catch blocks.

For compatibility a special mode can be added in principle to Rhino from 
mozilla.org with support for arguments.continuation and catch(...) with 
the clear marks about deprecation (unless, of cause, it is possible to 
implement the constructions simply and efficiently - then no 
deprecation!). But my continuation curiosity does not spread far enough 
to create such patch.

Regards, Igor

Mime
View raw message