5Notational Conventions
5.1Grammars
5.1.1Context-Free Grammars
A context-free grammar consists of a number of productions. Each production has an abstract symbol called a nonterminal as its left-hand side, and a sequence of zero or more nonterminal and terminal symbols as its right-hand side.
A chain production is a production that has exactly one nonterminal symbol on its right-hand side along with zero or more terminal symbols.
5.1.2The Lexical and RegExp Grammars
A lexical grammar defines a set of productions, starting from the goal symbol InputElementDiv, InputElementTemplateTail, or InputElementRegExp, or InputElementRegExpOrTemplateTail.
A example of InputElementRegExp can be /a_Pattern/flags , refer to A.8 for Pattern, the RegExp Grammars.
InputElementDiv can be spaces, comments, and so on.
An example of InputElementRegExpOrTemplateTail can be
`hello,${expr
},it's funny, I like python's """multi_line_str"""`
In the example of InputElementRegExpOrTemplateTail, "}...`" is a InputElementTemplateTail, which terminates this goal symbol.
Input elements other than white space, line terminators, and comments form the terminal symbols for the syntactic grammar for ECMAScript and are called ECMAScript tokens.
A MultiLineComment is simply discarded if it contains no line terminator; but if a MultiLineComment contains one or more line terminators, then it is replaced by a single line terminator, which becomes part of the stream of input elements for the syntactic grammar. Simple white space and single-line comments are discarded and do not appear in the stream of input elements.
Productions of the lexical and RegExp grammars are distinguished by having two colons “::” as separating punctuation.
5.1.3The Numeric String Grammar
Another grammar is used for translating Strings into numeric values. This grammar is similar to the part of the lexical grammar having to do with numeric literals. When found strings literals( begins with '"' or "'" ), the parser enters Numeric String parsing state( when found /a_Pattern/, ecma parser enters RegExp parsing state).
Productions of the numeric string grammar are distinguished by having three colons “:::” as punctuation.
5.1.4The Syntactic Grammar
The syntactic grammar for ECMAScript is given in clauses 11(Lexical Grammar), 12, 13, 14(Functions and Classes), and 15(Scripts and Modules). This grammar has ECMAScript tokens defined by the lexical grammar as its terminal symbols. It defines a set of productions, starting from two alternative goal symbols Script and Module, that describe how sequences of tokens form syntactically correct independent components of ECMAScript programs.
When a stream of code points is to be parsed as an ECMAScript Script or Module, it is first converted to a stream of input elements by repeated application of the lexical grammar; this stream of input elements is then parsed by a single application of the syntactic grammar. The input stream is syntactically in error if the tokens in the stream of input elements cannot be parsed as a single instance of the goal nonterminal (Script or Module), with no tokens left over.
When a parse is successful, it constructs a parse tree, a rooted tree structure in which each node is a Parse Node. Each Parse Node is an instance of a symbol in the grammar; it represents a span of the source text that can be derived from that symbol. The root node of the parse tree, representing the whole of the source text, is an instance of the parser's goal symbol. When a Parse Node is an instance of a nonterminal, it is also an instance of some production that has that nonterminal as its left-hand side. Moreover, it has zero or more children, one for each symbol on the production's right-hand side: each child is a Parse Node that is an instance of the corresponding symbol.
Productions of the syntactic grammar are distinguished by having just one colon “:” as punctuation.
5.1.5Grammar Notation
A production may be parameterized by a subscripted annotation of the form “[parameters]”
StatementList[AliasSuffix1, AliasSuffix2]: ReturnStatement ExpressionStatement is an abbreviation for: StatementList: ReturnStatement ExpressionStatement StatementList_AliasSuffix1: ReturnStatement ExpressionStatement StatementList_AliasSuffix2: ReturnStatement ExpressionStatement StatementList_AliasSuffix1_AliasSuffix2: ReturnStatement ExpressionStatement
References to nonterminals on the right-hand side of a production can also be parameterized. For example:
StatementList: ReturnStatement ExpressionStatement[+In] is equivalent to saying: StatementList: ReturnStatement ExpressionStatement_In and: StatementList: ReturnStatement ExpressionStatement[~In] is equivalent to: StatementList: ReturnStatement ExpressionStatement
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:
VariableDeclaration[In]: BindingIdentifierInitializer[?In] is an abbreviation for: VariableDeclaration: BindingIdentifierInitializer VariableDeclaration_In: BindingIdentifierInitializer_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 was not used in referencing the production's nonterminal symbol. This means that:
StatementList[Return]: [+Return]ReturnStatement ExpressionStatement is an abbreviation for: StatementList: ExpressionStatement StatementList_Return: ReturnStatement ExpressionStatement and that: StatementList[Return]: [~Return]ReturnStatement ExpressionStatement is an abbreviation for: StatementList: ReturnStatement ExpressionStatement StatementList_Return: ExpressionStatement
5.2Algorithm Conventions
some algorithms, called abstract operations, are named and written in parameterized functional form so that they may be referenced by name from within other algorithms. Calls to abstract operations return Completion Records.
Calls to abstract operations return Completion Records. Abstract operations referenced using the functional application style and the method application style that are prefixed by ? indicate that ReturnIfAbrupt should be applied to the resulting Completion Record. For example, ? operationName() is equivalent to ReturnIfAbrupt(operationName()). Similarly, ? someValue.operationName() is equivalent to ReturnIfAbrupt(someValue.operationName()).
The prefix ! is used to indicate that an abstract operation will never return an abrupt completion and that the resulting Completion Record's value field should be used in place of the return value of the operation. For example, “Let val be ! operationName()” is equivalent to the following algorithm steps:
Let val be operationName(). Assert: val is never an abrupt completion. If val is a Completion Record, let val be val.[[Value]].
Mathematical operations such as addition, subtraction, negation, multiplication, division, and the mathematical functions defined later in this clause should always be understood as computing exact mathematical results on mathematical real numbers, which unless otherwise noted do not include infinities and do not include a negative zero that is distinguished from positive zero. Algorithms in this standard that model floating-point arithmetic include explicit steps, where necessary, to handle infinities and signed zero and to perform rounding. If a mathematical operation or function is applied to a floating-point number, it should be understood as being applied to the exact mathematical value represented by that floating-point number; such a floating-point number must be finite, and if it is +0 or -0 then the corresponding mathematical value is simply 0.
When impl, it's a need to diff an mathematical operations from operations in this standard(modeling floating-point arithmetic).
The mathematical function floor(x) produces the largest integer (closest to positive infinity) that is not larger than x.
floor(x) = x-(x modulo 1).
5.3Static Semantic Rules
Context-free grammars are not sufficiently powerful to express all the rules that define whether a stream of input elements form a valid ECMAScript Script or Module. In some situations additional rules are needed that may be expressed using either ECMAScript algorithm conventions. Such rules are always associated with a production of a grammar and are called the static semantics of the production.
Static Semantic Rules have names and typically are defined using an algorithm. Named Static Semantic Rules are associated with grammar productions and a production that has multiple alternative definitions will typically have for each alternative a distinct algorithm for each applicable named static semantic rule.
A special kind of static semantic rule is an Early Error Rule. Early error rules define early error conditions (see clause 16) that are associated with specific grammar productions. Evaluation of most early error rules are not explicitly invoked within the algorithms of this specification. A conforming implementation must, prior to the first evaluation of a Script or Module, validate all of the early error rules of the productions used to parse that Script or Module. If any of the early error rules are violated the Script or Module is invalid and cannot be evaluated.
