Strict mode eval

Andreas Rossberg rossberg at
Wed May 11 10:31:34 PDT 2011

On 11 May 2011 18:31, Mark S. Miller <erights at> wrote:
> On Wed, May 11, 2011 at 4:42 AM, Andreas Rossberg <rossberg at>
> wrote:
>> Thanks to everybody for clearing up my confusion. The thing I had
>> missed in the spec was Section 10.4.2. And of course, my example was
>> too simplistic because it couldn't distinguish caller and global
>> context.
>> At the risk of reviving old discussions, are there any sources
>> explaining the rationale behind the current design? The "obvious"
>> solution to me would have been having two internal variants/modes of
>> (or "entry points" to) the eval function, one strict, one non-strict.
>> And depending on the lexical strict mode, the identifier "eval" would
>> be bound to the right one.
> I don't think I understand the suggestion. What would the following code do:
>     // non-strict outer context
>     function f(eval) {
>       var f = eval;
>       function g() {
>         "use strict";
>         eval(str); // [1]
>         (1,eval)(str); // [2]
>         f(str); // [3]
>       }
>     }
> [1] If the outer eval is bound to the global eval function then this is a
> direct eval, which therefore lexically inherits strictness. So no problem
> here.
> [2] The 'eval' identifier is bound in non-strict code and used in strict
> code.
> [3] Strict code makes no use here of a lexical binding of the identifier
> "eval".
> A previous approach which we rejected was to make strictness dynamically
> scoped, so all three of the above calls would do strict evals. This was
> rejected to avoid the problems of dynamic scoping. Are you suggesting a rule
> that would affect #2 but not #3? If so, IIRC no such rule was previously
> proposed.

I'm actually suggesting plain lexical scoping. :)

Basically, what I'm saying is that the directive "use strict" could
simply amount to shadowing the global eval via an implicit "var eval =
eval_strict" (unless global eval has already been shadowed lexically).
So all uses of the identifier `eval' in that scope would refer to its
strict version, no matter when, where, or how you ultimately invoke
it. Consequently, all your three examples would behave the same, only
depending on the argument to f.

Re dynamic scoping: in fact, I would claim that the current rule _is_
a form of dynamic scoping -- eval behaves differently when its caller
is strict. Except that this rule only applies when the syntactic
identifier in the call happens to be "eval". Regardless of the above,
I wonder why this special case was introduced. Why is the rule not
applied to all applications uniformly? I feel that I am missing


More information about the es-discuss mailing list