diff --git a/spec.html b/spec.html index 458ef5985a..cec6468317 100644 --- a/spec.html +++ b/spec.html @@ -819,8 +819,17 @@
If the phrase “[lookahead = _seq_]” appears in the right-hand side of a production, it indicates that the production may only be used if the token sequence _seq_ is a prefix of the immediately following input token sequence. Similarly, “[lookahead ∈ _set_]”, where _set_ is a finite non-empty set of token sequences, indicates that the production may only be used if some element of _set_ is a prefix of the immediately following token sequence. For convenience, the set can also be written as a nonterminal, in which case it represents the set of all token sequences to which that nonterminal could expand. It is considered an editorial error if the nonterminal could expand to infinitely many distinct token sequences.
-These conditions may be negated. “[lookahead ≠ _seq_]” indicates that the containing production may only be used if _seq_ is not a prefix of the immediately following input token sequence, and “[lookahead ∉ _set_]” indicates that the production may only be used if no element of _set_ is a prefix of the immediately following token sequence.
+When a phrase of the form “[lookahead …]” appears in the right-hand side of a production, it indicates that the production may only be used if the “lookahead” (the items that immediately follow the corresponding point in the input) satisfies a specified constraint. If the production is in the syntactic grammar, the items of the lookahead are input elements (mainly tokens); otherwise, they are code points.
+The forms of lookahead restriction, along with the constraint that each imposes on the lookahead, are as follows:
+In the above, _pattern_ is a set of one or more alternatives, separated by `|`. It matches the lookahead if any of its alternatives matches the lookahead. Each alternative is a sequence of one or more terminal and nonterminal symbols from the grammar of the containing production. In the syntactic grammar, such a sequence may also include a "[no LineTerminator here]" phrase. A sequence matches the lookahead if some prefix of the lookahead can be parsed according to that sequence.
+In effect, the alternatives of _pattern_ are the right-hand sides of an anonymous nonterminal, and the parser must attempt to recognize an instance of that nonterminal starting at the corresponding point in the input. If it can, _pattern_ matches the lookahead.
+To make this feasible, there are restrictions on _pattern_. In the syntactic grammar, _pattern_ must not involve nonterminals. In other grammars, _pattern_ must be equivalent to a regular expression over code points. Any violation of these restrictions is considered an editorial error.
As an example, given the definitions:
the definition:
matches either the letter `n` followed by one or more decimal digits the first of which is even, or a decimal digit not followed by another decimal digit.
-Note that when these phrases are used in the syntactic grammar, it may not be possible to unambiguously identify the immediately following token sequence because determining later tokens requires knowing which lexical goal symbol to use at later positions. As such, when these are used in the syntactic grammar, it is considered an editorial error for a token sequence _seq_ to appear in a lookahead restriction (including as part of a set of sequences) if the choices of lexical goal symbols to use could change whether or not _seq_ would be a prefix of the resulting token sequence.
+Note that when a lookahead restriction is used in the syntactic grammar, it may not be possible to unambiguously identify the tokens in the lookahead because determining later tokens requires knowing which lexical goal symbol to use at later positions. As such, when a lookahead restriction is used in the syntactic grammar, it is considered an editorial error if the choices of lexical goal symbols to use could change whether or not the restriction's _pattern_ would match the lookahead.
An |ExpressionStatement| cannot start with a U+007B (LEFT CURLY BRACKET) because that might make it ambiguous with a |Block|. An |ExpressionStatement| cannot start with the `function` or `class` keywords because that would make it ambiguous with a |FunctionDeclaration|, a |GeneratorDeclaration|, or a |ClassDeclaration|. An |ExpressionStatement| cannot start with `async function` because that would make it ambiguous with an |AsyncFunctionDeclaration| or a |AsyncGeneratorDeclaration|. An |ExpressionStatement| cannot start with the two token sequence `let [` because that would make it ambiguous with a `let` |LexicalDeclaration| whose first |LexicalBinding| was an |ArrayBindingPattern|.
@@ -21588,9 +21597,9 @@The syntax of
The syntax of
This alternative pattern grammar and semantics only changes the syntax and semantics of BMP patterns. The following grammar extensions include productions parameterized with the [UnicodeMode] parameter. However, none of these extensions change the syntax of Unicode patterns recognized when parsing with the [UnicodeMode] parameter present on the goal symbol.
The semantics of
The semantics of
CompileAtom rules for the |Atom| productions except for
This production only applies when parsing non-strict code. Source text matched by this production is processed as if each matching occurrence of |FunctionDeclaration[?Yield, ?Await, ~Default]| was the sole |StatementListItem| of a |BlockStatement| occupying that position in the source text. The semantics of such a synthetic |BlockStatement| includes the web legacy compatibility semantics specified in