Editorial: Remove unused steps from definitions of Contains

[jmdyck]

... specifically, steps of the form:

    If _symbol_ is an |Identifier| and StringValue of _symbol_
    is the same value as the StringValue of |IdentifierName|,
    return *true*.

Resolves #831.

As @allenwb points out, the intended use case for such steps does not occur in the spec.

And as I point out, these steps are semantically problematic.

If the intended use case ever does occur, I suspect we'll find a different way to handle it.

[zenparsing]

If the intended use case ever does occur, I suspect we'll find a different way to handle it.

Such as introducing a new static semantic rule like "ContainsIdentifier" or somesuch?

[jmdyck]

Such as introducing a new static semantic rule like "ContainsIdentifier" or somesuch?

Yup, e.g. ContainsArguments in the Public and private instance fields proposal.

Or we might try to introduce a form that abstracts over this kind of ContainsFoo operation, so that defining a new one isn't too burdensome.

[waldemarhorwat]

Is Contains ever used with identifiers?

If not, then it might be better to do the following:

• Delete these overrides of Contains
• Add an override of Contains on IdentifierName that always returns false so that IdentifierName doesn't pick up reserved words in any context.
• Clarify that Contains on reserved words not in IdentifierName does match

It's currently unclear where Contains stops. Does it jump from the syntactic grammar to the lexical grammar? I hope it doesn't, but the spec is ambiguous. While doing the above it would be good to clarify how Contains deals with that boundary (and on which side of that boundary reserved words and IdentifierName lie) in the definition of Contains.

[jmdyck]

Is Contains ever used with identifiers?

The right-hand argument of Contains is never |Identifier|, if that's what you mean.

Here are all the right-hand args:

`super`
|AwaitExpression|
|NewTarget|
|NotEscapeSequence|
|ScriptBody|
|SuperCall|
|SuperProperty|
|YieldExpression|

If not, then it might be better to do the following:

• Delete these overrides of Contains

• Add an override of Contains on IdentifierName that always returns false so that IdentifierName doesn't pick up reserved words in any context.

Yeah, I think that would work (assuming the syntactic/lexical boundary isn't a problem, see below).

* Clarify that Contains on reserved words not in IdentifierName does match

What do you mean by "reserved words not in IdentifierName"? It seems to me that there's no such thing. (That is, any sequence of characters that matches ReservedWord also matches IdentifierName.)

It's currently unclear where Contains stops. Does it jump from the syntactic grammar to the lexical grammar? I hope it doesn't, but the spec is ambiguous.

I believe it doesn't (currently) matter. That is, for the cases in which it is currently used, Contains will deliver the same result whether you think it jumps or not. (Mind you, I think there's a fair chance that a new use could break that without anyone noticing, so it's kind of fragile.)

While doing the above it would be good to clarify how Contains deals with that boundary (and on which side of that boundary reserved words and IdentifierName lie) in the definition of Contains.

It seems to me that the spec prefers to avoid talking about that boundary. Which might be one reason that these rules stop the recursion one step away from it.

[syg]

Removing the unused definitions lgtm. Though @jmdyck, what were your conclusions re: Waldemar's suggestions, that having them in the spec won't really help readability?

[bakkot]

Having just read some about this, two relevant details:

The syntactic grammar "has ECMAScript tokens defined by the lexical grammar as its terminal symbols".

Contains is defined to recurse on the nonterminal symbols on the RHS.

In particular, per the first point IdentifierName is a terminal symbol of the syntactic grammar, not a nonterminal. Therefore, per the second point, Contains would not recurse into it.

Strictly speaking this means that we could remove the four productions currently touched by this PR without adding any new ones, since all terminals effectively have a default definition of "return false". However, I think this would be more confusing than the current PR.

---

In other words, my reading is that the answer to @waldemarhorwat's question

It's currently unclear where Contains stops. Does it jump from the syntactic grammar to the lexical grammar? I hope it doesn't, but the spec is ambiguous.

is that it unambiguously does not jump to the lexical grammar (assuming my reading of the above two things are correct). And I don't really want to mess with that, so my preference is to stick with the current PR.

[jmdyck]

In particular, per the first point IdentifierName is a terminal symbol of the syntactic grammar, not a nonterminal. Therefore, per the second point, Contains would not recurse into it.

Except that it's definitely a nonterminal of the lexical grammar. So a given IdentifierName would seem to satisfy the condition in step 1.b ("child is an instance of a nonterminal"), suggesting that Contains would indeed recurse on it. However, the recursive invocation would in practice violate the 'assertion' that symbol "is a terminal or nonterminal of the grammar that includes the associated production".

So it's unclear, and I think it would be a spec bug if we ever allowed it to happen (under the current formulation).

(@syg, does that also answer your question?)

Strictly speaking this means that we could remove the four productions currently touched by this PR without adding any new ones, since all terminals effectively have a default definition of "return false".

(Other than when they actually match the symbol being searched for.)

However, I think this would be more confusing than the current PR.

Yeah. (It might be possible to make that approach clearer, but that's not currently on offer!)

[bakkot]

Except that it's definitely a nonterminal of the lexical grammar. So a given IdentifierName would seem to satisfy the condition in step 1.b ("child is an instance of a nonterminal")

Ah, I suppose that's fair. I read it to mean "a nonterminal of the grammar of which this production is a part", since one does not generally talk about nonterminals except in relation to a particular grammar.