effect of "IdentifierName but not ReservedWord"

[jmdyck]

Clause 12.1.1 has:

    Identifier : IdentifierName but not ReservedWord

    It is a Syntax Error if StringValue of |IdentifierName| is the same String
    value as the StringValue of any |ReservedWord| except for `yield`.

This combination is odd in a couple of ways:

(1) Ignoring "except for yield" for the moment, it seems that the Early Error rule makes the "but not ReservedWord" in the production superfluous. (The restriction in the Early Error rule is stronger than that of the production, because StringValue normalizes Unicode escape sequences.)

(2) Now considering "except for yield", it seems like the production is actually contradicting the Early Error rule: a parser that strictly obeys the production would never allow an Identifier spelled "yield" (because it's a Keyword, and thus a ReservedWord), yet the Early Error rule wants to allow it.

So it seems to me that either "but not ReservedWord" should be removed from the production for Identifier, or else yield should be dropped from the production for Keyword (with various collateral changes). I think I prefer the latter. Or both.

(I think this relates back to https://bugs.ecmascript.org/show_bug.cgi?id=2519 from @anba.)

[allenwb]

1. parsing and static semantics are not the same process. The but not prevents the parser from recognizing reserved words in contexts where an Identifier is required. This could lead to another production being recognized. For example, we want this to be recognized as PrimaryExpression : this rather than PrimaryExpression : IdentifierReference

Note that the ReservedWord production only matches the exact character sequecnes list. Character sequence that use escape sequences never match ReservedWord but are recognized as IdentifierName. The early error word prevents such escaped keyword-like sequences form being used as Identifers.

2. "yield" is never parsed as an Identifier because it is listed as a ReservedWord. But it can be parsed as an IdentifierReference, BindingIdentifier, or LabelIdentifer (see productions 12.1). The second static semantic rule on Identifier allows occurances of "yield" written using escapes to be processes as Identifer

"yield" and escaped "yield" can be used as Identifiers in non-strict, non-generator contexts. Other static semantic rules in 12.1.1 produce errors when "yield" (including escaped "yield") is used improperly in other contexts

[allenwb]

1. parsing and static semantics are not the same process. The but not prevents the parser from recognizing reserved words in contexts where an Identifier is required. This could lead to another production being recognized. For example, we want this to be recognized as PrimaryExpression : this rather than PrimaryExpression : IdentifierReference

Note that the ReservedWord production only matches the exact character sequecnes list. Character sequence that use escape sequences never match ReservedWord but are recognized as IdentifierName. The early error word prevents such escaped keyword-like sequences form being used as Identifers.

2. "yield" is never parsed as an Identifier because it is listed as a ReservedWord. But it can be parsed as an IdentifierReference, BindingIdentifier, or LabelIdentifer (see productions 12.1). The second static semantic rule on Identifier allows occurances of "yield" written using escapes to be processes as Identifer

"yield" and escaped "yield" can be used as Identifiers in non-strict, non-generator contexts. Other static semantic rules in 12.1.1 produce errors when "yield" (including escaped "yield") is used improperly in other contexts

[jmdyck]

Okay, that mostly makes sense to me. Except when you say:

"yield" and escaped "yield" can be used as Identifiers in non-strict, non-generator contexts.

I think it would be more accurate to say:

• unescaped "yield" can be used like an Identifier in such contexts, although it isn't technically an Identifier.
• escaped "yield" is indeed an Identifier is such contexts.

[jmdyck]

Okay, that mostly makes sense to me. Except when you say:

"yield" and escaped "yield" can be used as Identifiers in non-strict, non-generator contexts.

I think it would be more accurate to say:

• unescaped "yield" can be used like an Identifier in such contexts, although it isn't technically an Identifier.
• escaped "yield" is indeed an Identifier is such contexts.

[allenwb]

Okay, that mostly makes sense to me. Except...

My statement is essentially the user view of how yield can be used. Your statement summaries how that view is specified.

[allenwb]

Okay, that mostly makes sense to me. Except...

My statement is essentially the user view of how yield can be used. Your statement summaries how that view is specified.

[jmdyck]

Yup. Maybe I'll propose a Note to make this clearer, but that'll be separate.

[jmdyck]

Yup. Maybe I'll propose a Note to make this clearer, but that'll be separate.