Strict mode eval

felix felix8a at gmail.com
Wed May 11 11:41:47 PDT 2011


I think he's proposing that the 'eval' function would be a magical
function that can inspect its calling environment to determine whether
it's being called in a lexically strict context or not, and based on
that it would act like the strict eval operator, or not.

On Wed, May 11, 2011 at 11:30, Mark S. Miller <erights at google.com> wrote:
>
>
> On Wed, May 11, 2011 at 10:31 AM, Andreas Rossberg <rossberg at google.com>
> wrote:
>>
>> On 11 May 2011 18:31, Mark S. Miller <erights at google.com> wrote:
>> > 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.
>>
>> 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.
>
> I don't understand. If "use strict" implicitly introduces a "var eval =
> eval_strict;" at the position it occurs, then wouldn't #3 in my example
> still evaluate non-strict?
> I'll answer the rest once I understand your proposal.
>>
>> 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
>> something.
>>
>> /Andreas
>
>
>
> --
>     Cheers,
>     --MarkM
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


More information about the es-discuss mailing list