Brendan,
You're beating a dead horse here. If this call to eval is allowed, the only
reasonable answer is 21. All that means is that you must be able to recreate
the bindings if the function uses eval. Unless you're proposing to take
block-scoped declarations out of ES4, what's the harm with ES3.1 having a
compatible subset of them?
Waldemar
Brendan Eich wrote:
> On Jul 10, 2008, at 3:28 PM, Mark S. Miller wrote:
>
>> On Thu, Jul 10, 2008 at 2:51 PM, Allen Wirfs-Brock
>> <[EMAIL PROTECTED]
>> <mailto:[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
> <http://www.nabble.com/Eval-invisible-let-bindings-td14182651.html%2523a14182651>"
>
> 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
