On Wed, May 11, 2011 at 11:41 AM, felix <[email protected]> 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 <[email protected]> wrote: > > > > > > On Wed, May 11, 2011 at 10:31 AM, Andreas Rossberg <[email protected]> > > wrote: > >> > >> On 11 May 2011 18:31, Mark S. Miller <[email protected]> wrote: > >> > On Wed, May 11, 2011 at 4:42 AM, Andreas Rossberg < > [email protected]> > >> > 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 > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > > > > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
