Update on ES3.1 block scoped function declarations
brendan at mozilla.org
Thu Jul 10 15:50:20 PDT 2008
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
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
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es4-discuss