Update on ES3.1 block scoped function declarations

[Maciej Stachowiak]

On Jul 10, 2008, at 3:28 PM, Mark S. Miller wrote:

> On Thu, Jul 10, 2008 at 2:51 PM, Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com 
> > wrote:
> I see, yes there is a potential eval tax.  If I thought this was  
> really a concern (and as you say, we already have the issue for  
> catch and such) I'd be more inclined to fiddling with the scoping  
> rule of eval rather than discarding lexically scoped consts.  BTW, I  
> think many of the use cases for such const are more in support of  
> code generators then actual end user programming.
>
> Could you explain the "eval tax" issue you guys are concerned about?  
> I don't get it. Thanks.

Because eval exposes lexical bindings by name in a way that is not  
statically detectable, it defeats implementation techniques like  
renaming or symbol versioning for block scope, and forces the use of  
actual environment objects for blocks if they contain a call to eval.  
For example:

function g(x)
{
     if (x) {
         const C = 0;
         return eval(s1);
     } else {
         const C = 1;
         return eval(s2);
     }
}

Assuming s1 and s2 reference C, you at minimum need a separate runtime  
symbol table for each block to allow the eval lookup to succeed. When  
combined with closures and mutable block-scoped variables this can  
force the creation of a full activation object per block that  
introduces bindings.

And to avoid creating an activation object for every block (a huge  
performance cost), an implementation would have to detect which blocks  
introduce bindings, which contain calls to eval, and which contain  
closures. Reasonable implementations do this anyway but I think it is  
an unfortunate cost, even in ES4. In ES4, however, the benefit is  
arguably greater.

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20080710/60ae4db4/attachment-0002.html