Eval-invisible let bindings

[Lars Hansen]

> -----Original Message-----
> From: es4-discuss-bounces at mozilla.org 
> [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Igor Bukanov
> Sent: 5. desember 2007 23:53
> To: es4-discuss at mozilla.org
> Subject: Eval-invisible let bindings
> 
> Hi,
> 
> Currently ES4 allows to access from eval scripts the names 
> introduced by the let statements and expressions. It leads to 
> implementation complexity since the let bindings cannot be 
> implemented as a pure compilation-time feature and the 
> runtime must be able to expose the names for eval scripts.

Welcome to the wonderful world of "eval"!

> Thus I suggest to consider making let bindings invisible to 
> the eval scripts. That is, the idea is to exclude any 
> let-induced name from the scope chain passed to the eval 
> script. For example, given:
> 
> let a;
> function f(b) {
>     var c;
>     let d;
>     eval(eval_source);
> }
> 
> the script from eval_source when executed would not see a and 
> d and would be able to access/modify only b and c.

My opinion is that this would make things unnecessarily confusing.
Unless I'm mistaken we already have a couple of cases where names are
resolved at compile-time without taking into account shadowing bindings
introduced by "with" or "eval".  (The issue needs to be clarified
further.)  Adding more of those would not be good.

> This not only simplifies implementations, but would also give 
> a possibility to prevent eval-injections from discovering the 
> internal state of a closure as long as the closure uses let 
> for its internal state. Although ES4 mitigates that with 
> restrictions on the indirect eval, for compatibility 
> implementations may be forced to support it.

It simplifies some kinds of implementations.  Other implementations may
not be particularly affected by this problem.  My opinion is that people
who use the eval operator deserve what they get, and that the compiler
should feel free to generate slow code in any scope affected by a use of
the eval operator.  Such an implementation only needs to detect direct
uses of eval, as specified in ES3 and elaborated in ES4.   (ES4
specifies the meaning of strictly more uses of eval than ES3, and
requries that EvalError is thrown in other cases.)

--lars