Movatterモバイル変換

)

states that the nonterminalWhileStatement represents the tokenwhile, followed by a left parenthesis token, followed by anExpression, followed by a right parenthesis token, followed by aStatement. The occurrences ofExpression andStatement are themselves nonterminals. As another example, the syntactic definition:

states that anArgumentList may represent either a singleAssignmentExpression or anArgumentList, followed by a comma, followed by anAssignmentExpression. This definition ofArgumentList is recursive, that is, it is defined in terms of itself. The result is that anArgumentList may contain any positive number of arguments, separated by commas, where each argument expression is anAssignmentExpression. Such recursive definitions of nonterminals are common.

5.1.5.3 Optional Symbols

The subscripted suffix “_opt”, which may appear after a terminal or nonterminal, indicates an optional symbol. The alternative containing the optional symbol actually specifies two right-hand sides, one that omits the optional element and one that includes it. This means that:

opt

is a convenient abbreviation for:

and that:

for

(

opt

;

opt

)

is a convenient abbreviation for:

ForStatement

for

(

;

opt

)

for

(

;

opt

)

which in turn is an abbreviation for:

ForStatement

for

(

;

)

for

(

;

)

for

(

;

)

for

(

;

)

so, in this example, the nonterminalForStatement actually has four alternative right-hand sides.

5.1.5.4 Grammatical Parameters

A production may be parameterized by a subscripted annotation of the form “_[parameters]”, which may appear as a suffix to the nonterminal symbol defined by the production. “_parameters” may be either a single name or a comma separated list of names. A parameterized production is shorthand for a set of productions defining all combinations of the parameter names, preceded by an underscore, appended to the parameterized nonterminal symbol. This means that:

[Return]

is a convenient abbreviation for:

and that:

[Return, In]

is an abbreviation for:

StatementList_Return_In

Multiple parameters produce a combinatoric number of productions, not all of which are necessarily referenced in a complete grammar.

References to nonterminals on the right-hand side of a production can also be parameterized. For example:

[+In]

is equivalent to saying:

ExpressionStatement_In

and:

[~In]

is equivalent to:

A nonterminal reference may have both a parameter list and an “_opt” suffix. For example:

[+In]

opt

is an abbreviation for:

Initializer_In

Prefixing a parameter name with “_?” on a right-hand side nonterminal reference makes that parameter value dependent upon the occurrence of the parameter name on the reference to the current production's left-hand side symbol. For example:

[In]

[?In]

is an abbreviation for:

VariableDeclaration_In

Initializer_In

If a right-hand side alternative is prefixed with “[+parameter]” that alternative is only available if the named parameter was used in referencing the production's nonterminal symbol. If a right-hand side alternative is prefixed with “[~parameter]” that alternative is only available if the named parameter wasnot used in referencing the production's nonterminal symbol. This means that:

[Return]

[+Return]

is an abbreviation for:

and that:

[Return]

[~Return]

is an abbreviation for:

5.1.5.5 one of

When the words “one of” follow the colon(s) in a grammar definition, they signify that each of the terminal symbols on the following line or lines is an alternative definition. For example, the lexical grammar for ECMAScript contains the production:

NonZeroDigit

one of

which is merely a convenient abbreviation for:

NonZeroDigit

5.1.5.6 [empty]

If the phrase “[empty]” appears as the right-hand side of a production, it indicates that the production's right-hand side contains no terminals or nonterminals.

5.1.5.7 Lookahead Restrictions

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 sequenceseq is a prefix of the immediately following input token sequence. Similarly, “[lookahead ∈set]”, whereset is afinite non-empty set of token sequences, indicates that the production may only be used if some element ofset 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 ifseq isnot a prefix of the immediately following input token sequence, and “[lookahead ∉set]” indicates that the production may only be used ifno element ofset is a prefix of the immediately following token sequence.

As an example, given the definitions:

one of

the definition:

[lookahead ∉ {1,3,5,7,9 }]

DecimalDigits

DecimalDigit

[lookahead ∉DecimalDigit]

matches either the lettern 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 lexicalgoal 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 sequenceseq to appear in a lookahead restriction (including as part of a set of sequences) if the choices of lexicalgoal symbols to use could change whether or notseq would be a prefix of the resulting token sequence.

5.1.5.8 [noLineTerminator here]

If the phrase “[noLineTerminator here]” appears in the right-hand side of a production of the syntactic grammar, it indicates that the production isa restricted production: it may not be used if aLineTerminator occurs in the input stream at the indicated position. For example, the production:

ThrowStatement

throw

[noLineTerminator here]

;

indicates that the production may not be used if aLineTerminator occurs in the script between thethrow token and theExpression.

Unless the presence of aLineTerminator is forbidden by a restricted production, any number of occurrences ofLineTerminator may appear between any two consecutive tokens in the stream of input elements without affecting the syntactic acceptability of the script.

5.1.5.9 but not

The right-hand side of a production may specify that certain expansions are not permitted by using the phrase “but not” and then indicating the expansions to be excluded. For example, the production:

Identifier

IdentifierName

but notReservedWord

means that the nonterminalIdentifier may be replaced by any sequence of code points that could replaceIdentifierName provided that the same sequence of code points could not replaceReservedWord.

5.1.5.10 Descriptive Phrases

Finally, a few nonterminal symbols are described by a descriptive phrase in sans-serif type in cases where it would be impractical to list all the alternatives:

SourceCharacter

any Unicode code point

5.2 Algorithm Conventions

The specification often uses a numbered list to specify steps in an algorithm. These algorithms are used to precisely specify the required semantics of ECMAScript language constructs. The algorithms are not intended to imply the use of any specific implementation technique. In practice, there may be more efficient algorithms available to implement a given feature.

Algorithms may be explicitly parameterized with an ordered, comma-separated sequence of alias names which may be used within the algorithm steps to reference the argument passed in that position. Optional parameters are denoted with surrounding brackets ([ ,name ]) and are no different from required parameters within algorithm steps. A rest parameter may appear at the end of a parameter list, denoted with leading ellipsis (, ...name). The rest parameter captures all of the arguments provided following the required and optional parameters into aList. If there are no such additional arguments, thatList is empty.

Algorithm steps may be subdivided into sequential substeps. Substeps are indented and may themselves be further divided into indented substeps. Outline numbering conventions are used to identify substeps with the first level of substeps labelled with lowercase alphabetic characters and the second level of substeps labelled with lowercase roman numerals. If more than three levels are required these rules repeat with the fourth level using numeric labels. For example:

Top-level step
1. Substep.
2. Substep.
  1. Subsubstep.
    1. Subsubsubstep
      1. Subsubsubsubstep
        Subsubsubsubsubstep

A step or substep may be written as an “if” predicate that conditions its substeps. In this case, the substeps are only applied if the predicate is true. If a step or substep begins with the word “else”, it is a predicate that is the negation of the preceding “if” predicate step at the same level.

A step may specify the iterative application of its substeps.

A step that begins with “Assert:” asserts an invariant condition of its algorithm. Such assertions are used to make explicit algorithmic invariants that would otherwise be implicit. Such assertions add no additional semantic requirements and hence need not be checked by an implementation. They are used simply to clarify algorithms.

Algorithm steps may declare named aliases for any value using the form “Letx besomeValue”. These aliases are reference-like in that bothx andsomeValue refer to the same underlying data and modifications to either are visible to both. Algorithm steps that want to avoid this reference-like behaviour should explicitly make a copy of the right-hand side: “Letx be a copy ofsomeValue” creates a shallow copy ofsomeValue.

Once declared, an alias may be referenced in any subsequent steps and must not be referenced from steps prior to the alias's declaration. Aliases may be modified using the form “Setx tosomeOtherValue”.

5.2.1 Abstract Operations

In order to facilitate their use in multiple parts of this specification, some algorithms, calledabstract operations, are named and written in parameterized functional form so that they may be referenced by name from within other algorithms. Abstract operations are typically referenced using a functional application style such as OperationName(arg1,arg2). Some abstract operations are treated as polymorphically dispatched methods of class-like specification abstractions. Such method-like abstract operations are typically referenced using a method application style such assomeValue.OperationName(arg1,arg2).

5.2.2 Syntax-Directed Operations

Asyntax-directed operation is a named operation whose definition consists of algorithms, each of which is associated with one or more productions from one of the ECMAScript grammars. A production that has multiple alternative definitions will typically have a distinct algorithm for each alternative. When an algorithm is associated with a grammar production, it may reference the terminal and nonterminal symbols of the production alternative as if they were parameters of the algorithm. When used in this manner, nonterminal symbols refer to the actual alternative definition that is matched when parsing the source text. Thesource text matched by a grammar production orParse Node derived from it is the portion of the source text that starts at the beginning of the first terminal that participated in the match and ends at the end of the last terminal that participated in the match.

When an algorithm is associated with a production alternative, the alternative is typically shown without any “[ ]” grammar annotations. Such annotations should only affect the syntactic recognition of the alternative and have no effect on the associated semantics for the alternative.

Syntax-directed operations are invoked with a parse node and, optionally, other parameters by using the conventions on steps1,3, and4 in the following algorithm:

Letstatus be SyntaxDirectedOperation ofSomeNonTerminal.
LetsomeParseNode be the parse of some source text.
Perform SyntaxDirectedOperation ofsomeParseNode.
Perform SyntaxDirectedOperation ofsomeParseNode with argument"value".

Unless explicitly specified otherwise, allchain productions have an implicit definition for every operation that might be applied to that production's left-hand side nonterminal. The implicit definition simply reapplies the same operation with the same parameters, if any, to thechain production's sole right-hand side nonterminal and then returns the result. For example, assume that some algorithm has a step of the form: “ReturnEvaluation ofBlock” and that there is a production:

Block

{

}

but theEvaluation operation does not associate an algorithm with that production. In that case, theEvaluation operation implicitly includes an association of the form:

Runtime Semantics:Evaluation

Block

{