Discuss
  • assignment to eval in strict code

assignment to eval in strict code

# Allen Wirfs-Brock (17 years ago)

Now that we have decided that all declarations of the identifier "eval" are banned from strict code a related question has come up from one of the implementers of our strict mode prototype implementation. Why does Es3.1 still allow assignment to the identifier "eval" within strict code? That does seem like a logical extension of the arguments that convinced us to ban strict mode eval declaration. Does anyone have a reason why such an assignment would be a reasonable thing.

Adding that assignment restriction is a bit of a feature creep but something that is probably manageable in the time we have left if the consensus is that it makes sense to do.

Thoughts?

# Mark Miller (17 years ago)

I'd be happier with the restriction than without.

2009/2/12 Allen Wirfs-Brock <Allen.Wirfs-Brock at microsoft.com>

# Brendan Eich (17 years ago)

I wouldn't worry about feature creep in terms of strict mode
forbidding certain identifiers in unambiguous grammatical positions.
Some implementations already have to work harder if arguments is the
left-hand side of assignment within a function. Such parser tweaks are
also easier to get right that the complicated mix of static and
runtime checking required to implement eval and arguments in ES3 today.

Feature creep would be adding any more methods to Object, e.g.
(although IIRC there's a case to be made by Allen for
Object.hashcode ;-)).

More on an eval issue that I misremembered at the January meeting in a
separate post. It and things like it we don't know about are the
bigger threats to schedule than the strict mode refinements that
amount to making certain identifiers reserved.

# Mark S. Miller (17 years ago)

2009/2/12 Brendan Eich <brendan at mozilla.com>:

I wouldn't worry about feature creep in terms of strict mode forbidding certain identifiers in unambiguous grammatical positions. Some implementations already have to work harder if arguments is the left-hand side of assignment within a function. Such parser tweaks are also easier to get right that the complicated mix of static and runtime checking required to implement eval and arguments in ES3 today. Feature creep would be adding any more methods to Object, e.g. (although IIRC there's a case to be made by Allen for Object.hashcode ;-)). More on an eval issue that I misremembered at the January meeting in a separate post. It and things like it we don't know about are the bigger threats to schedule than the strict mode refinements that amount to making certain identifiers reserved.

Good. So does anyone object to ES3.1-strict imposing the same restrictions on the magic name "arguments" as we will on "eval"?

# Waldemar Horwat (17 years ago)

Allen Wirfs-Brock wrote:

Now that we have decided that all declarations of the identifier “eval” are banned from strict code a related question has come up from one of the implementers of our strict mode prototype implementation. Why does Es3.1 still allow assignment to the identifier “eval” within strict code? That does seem like a logical extension of the arguments that convinced us to ban strict mode eval declaration. Does anyone have a reason why such an assignment would be a reasonable thing.

Adding that assignment restriction is a bit of a feature creep but something that is probably manageable in the time we have left if the consensus is that it makes sense to do.

Thoughts?

Allen

How would you ban it? Would you make every property and variable read-only if its name happens to be "eval"?

Waldemar
# Mark Miller (17 years ago)

On Thu, Feb 12, 2009 at 5:17 PM, Waldemar Horwat <waldemar at google.com>wrote:

Allen Wirfs-Brock wrote:

Now that we have decided that all declarations of the identifier "eval" are banned from strict code a related question has come up from one of the implementers of our strict mode prototype implementation. Why does Es3.1 still allow assignment to the identifier "eval" within strict code? That does seem like a logical extension of the arguments that convinced us to ban strict mode eval declaration. Does anyone have a reason why such an assignment would be a reasonable thing.

Adding that assignment restriction is a bit of a feature creep but something that is probably manageable in the time we have left if the consensus is that it makes sense to do.

Thoughts?

Allen

How would you ban it? Would you make every property and variable read-only if its name happens to be "eval"?

Ban it by a purely syntactic rule affecting only variables, not properties.

eval = 8;

and

var eval = 8;

would be statically rejected in strict code, but

x.eval = 8;

would be fine, even if x turns out to be the global object. Of course, if other code in that frame has already frozen the 'eval' property of the global object, then the property assignment would fail as well. But this has nothing to do with strict mode, and needs no additional machinery in the ES3.1 spec.

# David-Sarah Hopwood (17 years ago)

Allen Wirfs-Brock wrote:

Now that we have decided that all declarations of the identifier "eval" are banned from strict code a related question has come up from one of the implementers of our strict mode prototype implementation. Why does Es3.1 still allow assignment to the identifier "eval" within strict code? That does seem like a logical extension of the arguments that convinced us to ban strict mode eval declaration. Does anyone have a reason why such an assignment would be a reasonable thing.

Adding that assignment restriction is a bit of a feature creep but something that is probably manageable in the time we have left if the consensus is that it makes sense to do.

The prohibition on declaring 'eval' makes more sense in conjunction with setting the properties of the global 'eval' property to be non-[[Writable]] and non-[[Configurable]]. That can't be done unconditionally for compatibility reasons, but it can be done in specific JavaScript contexts. There is otherwise little point in restricting assignment to 'eval' from strict code, if strict code can still see changes to it that were made from non-strict code.

# Allen Wirfs-Brock (17 years ago)

The easiest place to ban it would be in PutValue as References now carry sufficient state to identify them as simple identifier bindings in strict mode.

Allen

From: Mark Miller [mailto:erights at gmail.com] Sent: Thursday, February 12, 2009 5:24 PM To: Waldemar Horwat Cc: Allen Wirfs-Brock; es-discuss Subject: Re: assignment to eval in strict code

On Thu, Feb 12, 2009 at 5:17 PM, Waldemar Horwat <waldemar at google.com<mailto:waldemar at google.com>> wrote:

Allen Wirfs-Brock wrote: Now that we have decided that all declarations of the identifier "eval" are banned from strict code a related question has come up from one of the implementers of our strict mode prototype implementation. Why does Es3.1 still allow assignment to the identifier "eval" within strict code? That does seem like a logical extension of the arguments that convinced us to ban strict mode eval declaration. Does anyone have a reason why such an assignment would be a reasonable thing.

Adding that assignment restriction is a bit of a feature creep but something that is probably manageable in the time we have left if the consensus is that it makes sense to do.

Thoughts?

Allen

How would you ban it? Would you make every property and variable read-only if its name happens to be "eval"?

Ban it by a purely syntactic rule affecting only variables, not properties.

eval = 8;

and

var eval = 8;

would be statically rejected in strict code, but

x.eval = 8;

would be fine, even if x turns out to be the global object. Of course, if other code in that frame has already frozen the 'eval' property of the global object, then the property assignment would fail as well. But this has nothing to do with strict mode, and needs no additional machinery in the ES3.1 spec.

-- Text by me above is hereby placed in the public domain

# Allen Wirfs-Brock (17 years ago)

-----Original Message----- From: Mark S. Miller [mailto:erights at google.com] Sent: Thursday, February 12, 2009 4:58 PM

Good. So does anyone object to ES3.1-strict imposing the same restrictions on the magic name "arguments" as we will on "eval"?

In strict mode, "arguments" is already defined using an ImmutableBinding so assigning to it will fail in a manner similar to assignment to eval. We probably should list both of these assignment situations in section 16 as errors that can be reported at parse time.

As currently specified strict code can declare a formal parameter, var, or function named "arguments" but doing so blocks creation of an arguments object and its binding.

# Mark Miller (17 years ago)

On Wed, Feb 18, 2009 at 8:40 AM, Allen Wirfs-Brock < Allen.Wirfs-Brock at microsoft.com> wrote:

-----Original Message----- From: Mark S. Miller [mailto:erights at google.com] Sent: Thursday, February 12, 2009 4:58 PM

Good. So does anyone object to ES3.1-strict imposing the same restrictions on the magic name "arguments" as we will on "eval"?

In strict mode, "arguments" is already defined using an ImmutableBinding so assigning to it will fail in a manner similar to assignment to eval. We probably should list both of these assignment situations in section 16 as errors that can be reported at parse time.

As currently specified strict code can declare a formal parameter, var, or function named "arguments" but doing so blocks creation of an arguments object and its binding.

Yes. I am suggesting the such declarations not be allowed in strict code.