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- [EMAIL PROTECTED]> 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
_______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
