Strict mode eval

Mark S. Miller erights at google.com
Wed May 11 09:31:02 PDT 2011


On Wed, May 11, 2011 at 4:42 AM, Andreas Rossberg <rossberg at google.com>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.


> Thanks,
> /Andreas
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110511/402ffd6f/attachment.html>


More information about the es-discuss mailing list