Update on ES3.1 block scoped function declarations

[Brendan Eich]

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.


In ES1-3, the scope chain is a linked list of objects. Every function  
call creates an activation object to be the variable object used when  
"entering the execution context" for that function's code. Thus when  
entering the execution context for eval code, one uses the caller's  
scope chain.

Real implementations do not reify objects for all activations. This  
is a good way to be slow.

Separately, we aspire to lexical scope. This does not necessarily  
mean block scope, see e.g. ES4 comprehensions. But however it maps  
onto syntax, lexical scope holds out the hope that the binding  
information is compile-time only. After that, the implementation can  
forget about bindings and the lexical scopes they inhabit.

That's not possible if eval can see const bindings in ES3.1 as  
proposed, or let/const/sub-statement-function bindings in ES4. The  
"Previously" thread I cited talks about an alternative where eval  
cannot see lexical bindings. But that thread concluded (IMHO) with  
the victorious and inevitable usability argument that programmers  
would be greatly put out, as well as surprised, if eval could not see  
its caller's lexical bindings.

So implementations have to save lexical binding information when  
compiling, and reify or otherwise propagate it to eval.

Implementations that support indirect eval must not only save the  
lexical binding information, they must reify bindings as properties  
and scopes as objects (or something morally equivalent), since the  
compiler cannot see all eval calls and make a private arrangement to  
pass private binding/scope data structures preserved with the  
function or script that calls eval. The indirect eval activation  
really does need to see objects on a scope chain. This can be done on  
demand, but it is not pretty.

Imposing this tax on implementations of ES3.1 and not giving them let  
and function sub-statements seems half-hearted, and implementations  
are likely to extend.

Block scope is nice, but it's a big change for ES3.1. The alternative  
is to

a. confine const grammatically to top level where it can be treated  
like a property of the global or activation object in the spec, and

b. deal with eval referencing a catch variable or named lambda  
specially.

The (b) cases were specified in ES3 using "as if by new Object" or  
equivalent, which is a bug, but some implementations ignored ES3 and  
used lexical binding machinery. I'm not sure whether all such all  
eval to see such bindings. Firefox 2 and 3 do for catch variables.  
I'll test Opera and report back.

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