Strict mode eval
rossberg at google.com
Mon May 16 09:22:54 PDT 2011
Sure, sounds good. I will look into it.
On 14 May 2011 03:18, Mark S. Miller <erights at google.com> wrote:
> I think this is the kind of incremental refinement of the details of
> existing features that we can legitimately consider after May without
> setting a bad precedent. Would you be interested in turning these ideas into
> a strawman for, say, the July meeting?
> Unless there's a problem with this approach I'm not noticing, I think it
> would be a welcome cleanup of a messy part of the language -- conditioned on
> an ES-next opt in of course.
> On Fri, May 13, 2011 at 2:05 AM, Andreas Rossberg <rossberg at google.com>
>> On 13 May 2011 01:50, Mark S. Miller <erights at google.com> wrote:
>> >> Assume that
>> >> - we distinguish two variants of the eval function, strict and
>> >> non-strict -- let's call these values EVAL_s and EVAL_ns.
>> >> - initially (in global scope), the identifier `eval' is bound to
>> >> EVAL_ns.
>> >> - in a strict mode scope it will be considered rebound to EVAL_s
>> >> instead (unless it has already been shadowed by user code anyway).
>> >> (In addition, at least in strict mode, the only calls to `eval' that
>> >> are considered _direct_ calls would be those where `eval' statically
>> >> refers to the initial binding or one of the implicit strict-mode
>> >> rebindings -- i.e., where it has not been shadowed by the user.)
>> > I think the core insight here is good, and had it been made in time,
>> > could
>> > have led to a better semantics than what we adopted into ES5. I like the
>> > idea that ' "use strict";' effectively inserts a
>> > DeclarativeEnvironmentRecord binding 'eval' to EVAL_s, though I'd put
>> > this
>> > record on the stack at the strict/non-strict boundary rather than just
>> > above
>> > the global object.
>> Yes, my previous description of "shadowing" `eval' at the point of
>> "use strict" was meant to describe just that.
>> > Even better, since 'eval' cannot be rebound by ES5/strict, ES-next, or
>> > SES
>> > code, and since "eval(str)" is effectively a special form anyway, why
>> > not
>> > remove the dynamic "and if 'eval' is bound to the original global eval
>> > function" condition from direct eval? Why not just treat "eval(str)" as
>> > a
>> > direct eval special form independent of what 'eval' is bound to in that
>> > scope?
>> That's what I tried to suggest in the parenthesized paragraph above,
>> and it was the reason for my question to Allan.
>> The difficulty in ES5 would be that scoping is not really static --
>> not even in strict-mode code, which might still be surrounded by
>> non-script scopes shadowing `eval' dynamically (esp `with'). But for
>> Harmony it'd be nice.
More information about the es-discuss