cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Rhino from and continuations
Date Fri, 17 Sep 2004 22:11:23 GMT
Igor Bukanov wrote:

> 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.

Ok, that makes sense, as I didn't knew about these constraints and 

> 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.

Hey, that is a cool idea! Okay, let's keep Continuation() then.

>> 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 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.

"arguments.continuation", AFAIK was never documented publicly, so we can 
safely forget about it. For the special catch syntaxes, there will be 
some compatibility problems as many people are likely to have used it. 
But since the use of "finally" seems to allow the same kind of behaviour 
with a simpler syntax and a clearly specified semantics, I think it is 
our job, we cocooners, to prepare our user base to this change and give 
them directions to upgrade their scripts.

We've been wanting for long to get rid of the rhino fork which, although 
it brought us an amazingly powerful way of building webapps, brought 
also a lot of community and legal issues. So we can consider that 
upgrading our scripts is the price to pay for being able to use the 
official Mozilla Rhino, and those that don't want to upgrade will just 
be asked to keep the current rhino fork.


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message