Strict mode eval

Mark S. Miller erights at google.com
Wed May 11 11:51:24 PDT 2011


On Wed, May 11, 2011 at 11:41 AM, felix <felix8a at gmail.com> wrote:

> 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.
>

That's exactly what I'm trying to determine. Such magical dynamic inspection
of the caller's lexical context would be a form of dynamic scoping. Nowhere
else in the language can a callee detect a caller's strictness.



>
> 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
> >
> >
>



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


More information about the es-discuss mailing list