A syntax-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. The source text matched by a grammar production 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 steps 1, 3, and 4 in the following algorithm:
+Syntax-directed operations are invoked with a parse node and, optionally, other parameters by using the conventions on steps
Unless explicitly specified otherwise, all chain 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 the chain production's sole right-hand side nonterminal and then returns the result. For example, assume that some algorithm has a step of the form: “Return the result of evaluating |Block|” and that there is a production:
For implementations that provide more accurate conversions than required by the rules above, it is recommended that the following alternative version of step 5 be used as a guideline:
-For implementations that provide more accurate conversions than required by the rules above, it is recommended that the following alternative version of step
The object that may be created in step 5.a.ii is not accessible outside of the above abstract operation and the ordinary object [[Get]] internal method. An implementation might choose to avoid the actual creation of the object.
+The object that may be created in step
The object that may be created in step 6.a.ii is not accessible outside of the above abstract operation and the ordinary object [[Set]] internal method. An implementation might choose to avoid the actual creation of that object.
+The object that may be created in step
Given the above definition of ToUint32:
Given the above definition of ToUint16:
Step 3 differs from step 1.c in the algorithm that handles the addition operator `+` (
Step
The comparison of Strings uses a simple lexicographic ordering on sequences of code unit values. There is no attempt to use the more complex, semantically oriented definitions of character or string equality and collating order defined in the Unicode specification. Therefore String values that are canonically equal according to the Unicode standard could test as unequal. In effect this algorithm assumes that both Strings are already in normalized form. Also, note that for strings containing supplementary characters, lexicographic ordering on sequences of UTF-16 code unit values differs from that on sequences of code point values.
@@ -5632,7 +5632,7 @@Step 5 will only be reached if _obj_ is a non-standard function exotic object that does not have a [[Realm]] internal slot.
+Step
The concrete Environment Record method SetMutableBinding for declarative Environment Records attempts to change the bound value of the current binding of the identifier whose name is the value of the argument _N_ to the value of argument _V_. A binding for _N_ normally already exists, but in rare cases it may not. If the binding is an immutable binding, a *TypeError* is thrown if _S_ is *true*.
An example of ECMAScript code that results in a missing binding at step 2 is:
+An example of ECMAScript code that results in a missing binding at step
function f() { eval("var x; x = (delete x, 0);"); }Global function declarations are always represented as own properties of the global object. If possible, an existing own property is reconfigured to have a standard set of attribute values. Steps 8-9 are equivalent to what calling the InitializeBinding concrete method would do and if _globalObject_ is a Proxy will produce the same sequence of Proxy trap calls.
+Global function declarations are always represented as own properties of the global object. If possible, an existing own property is reconfigured to have a standard set of attribute values. Steps
The abstract operation GetThisEnvironment takes no arguments. It finds the Environment Record that currently supplies the binding of the keyword `this`. It performs the following steps when called:
The loop in step 2 will always terminate because the list of environments always ends with the global environment which has a `this` binding.
+The loop in step
The loop in step 8 guarantees that there will be no circularities in any prototype chain that only includes objects that use the ordinary object definitions for [[GetPrototypeOf]] and [[SetPrototypeOf]].
+The loop in step
When _calleeContext_ is removed from the execution context stack in step 8 it must not be destroyed if it is suspended and retained for later resumption by an accessible generator object.
+When _calleeContext_ is removed from the execution context stack in step
The [[Construct]] internal method for built-in function object _F_ is called with parameters _argumentsList_ and _newTarget_. The steps performed are the same as [[Call]] (see
The [[Construct]] internal method for built-in function object _F_ is called with parameters _argumentsList_ and _newTarget_. The steps performed are the same as [[Call]] (see
In steps 3 and 4, if _Desc_.[[Value]] is an object then its `valueOf` method is called twice. This is legacy behaviour that was specified with this effect starting with the 2nd Edition of this specification.
+In steps
A |CallExpression| evaluation that executes step 6.a.vi is a direct eval.
+A |CallExpression| evaluation that executes step
Steps 4 and 5 provide compatibility with previous editions of ECMAScript that did not use a @@hasInstance method to define the `instanceof` operator semantics. If an object does not define or inherit @@hasInstance it uses the default `instanceof` semantics.
+Steps
When an assignment occurs within strict mode code, it is a runtime error if _lref_ in step 1.e of the first algorithm or step 8 of the second algorithm is an unresolvable reference. If it is, a *ReferenceError* exception is thrown. The |LeftHandSideExpression| also may not be a reference to a data property with the attribute value { [[Writable]]: *false* }, to an accessor property with the attribute value { [[Set]]: *undefined* }, nor to a non-existent property of an object for which the IsExtensible predicate returns the value *false*. In these cases a *TypeError* exception is thrown.
+When an assignment occurs within strict mode code, it is a runtime error if _lref_ in step
The abstract operation ApplyStringOrNumericBinaryOperator takes arguments _lval_ (an ECMAScript language value), _opText_ (a sequence of Unicode code points), and _rval_ (an ECMAScript language value). It performs the following steps when called:
No hint is provided in the calls to ToPrimitive in steps 1.a and 1.b. All standard objects except Date objects handle the absence of a hint as if the hint Number were given; Date objects handle the absence of a hint as if the hint String were given. Exotic objects may handle the absence of a hint in some other manner.
+No hint is provided in the calls to ToPrimitive in steps
Step 1.c differs from step 3 of the Abstract Relational Comparison algorithm, by using the logical-or operation instead of the logical-and operation.
+Step
If a |VariableDeclaration| is nested within a with statement and the |BindingIdentifier| in the |VariableDeclaration| is the same as a property name of the binding object of the with statement's object Environment Record, then step 5 will assign _value_ to the property instead of assigning to the VariableEnvironment binding of the |Identifier|.
+If a |VariableDeclaration| is nested within a with statement and the |BindingIdentifier| in the |VariableDeclaration| is the same as a property name of the binding object of the with statement's object Environment Record, then step
An |ArrowFunction| does not define local bindings for `arguments`, `super`, `this`, or `new.target`. Any reference to `arguments`, `super`, `this`, or `new.target` within an |ArrowFunction| must resolve to a binding in a lexically enclosing environment. Typically this will be the Function Environment of an immediately enclosing function. Even though an |ArrowFunction| may contain references to `super`, the function object created in step 4 is not made into a method by performing MakeMethod. An |ArrowFunction| that references `super` is always contained within a non-|ArrowFunction| and the necessary state to implement `super` is accessible via the _scope_ that is captured by the function object of the |ArrowFunction|.
+An |ArrowFunction| does not define local bindings for `arguments`, `super`, `this`, or `new.target`. Any reference to `arguments`, `super`, `this`, or `new.target` within an |ArrowFunction| must resolve to a binding in a lexically enclosing environment. Typically this will be the Function Environment of an immediately enclosing function. Even though an |ArrowFunction| may contain references to `super`, the function object created in step
When the `hasOwnProperty` method is called with argument _V_, the following steps are taken:
The ordering of steps 1 and 2 is chosen to ensure that any exception that would have been thrown by step 1 in previous editions of this specification will continue to be thrown even if the *this* value is *undefined* or *null*.
+The ordering of steps
When the `isPrototypeOf` method is called with argument _V_, the following steps are taken:
The ordering of steps 1 and 2 preserves the behaviour specified by previous editions of this specification for the case where _V_ is not an object and the *this* value is *undefined* or *null*.
+The ordering of steps
When the `propertyIsEnumerable` method is called with argument _V_, the following steps are taken:
This method does not consider objects in the prototype chain.
The ordering of steps 1 and 2 is chosen to ensure that any exception that would have been thrown by step 1 in previous editions of this specification will continue to be thrown even if the *this* value is *undefined* or *null*.
+The ordering of steps
The _thisArg_ value is passed without modification as the *this* value. This is a change from Edition 3, where an *undefined* or *null* _thisArg_ is replaced with the global object and ToObject is applied to all other values and that result is passed as the *this* value. Even though the _thisArg_ is passed without modification, non-strict functions still perform these transformations upon entry to the function.
If _func_ is an arrow function or a bound function exotic object then the _thisArg_ will be ignored by the function [[Call]] in step 6.
+If _func_ is an arrow function or a bound function exotic object then the _thisArg_ will be ignored by the function [[Call]] in step
The _thisArg_ value is passed without modification as the *this* value. This is a change from Edition 3, where an *undefined* or *null* _thisArg_ is replaced with the global object and ToObject is applied to all other values and that result is passed as the *this* value. Even though the _thisArg_ is passed without modification, non-strict functions still perform these transformations upon entry to the function.
If _func_ is an arrow function or a bound function exotic object then the _thisArg_ will be ignored by the function [[Call]] in step 6.
+If _func_ is an arrow function or a bound function exotic object then the _thisArg_ will be ignored by the function [[Call]] in step
When a _NativeError_ function is called with argument _message_, the following steps are taken:
"%NativeError.prototype%", « [[ErrorData]] »).
+ 1. [id="step-nativerror-ordinarycreatefromconstructor"] Let _O_ be ? OrdinaryCreateFromConstructor(_newTarget_, "%NativeError.prototype%", « [[ErrorData]] »).
1. If _message_ is not *undefined*, then
1. Let _msg_ be ? ToString(_message_).
1. Let _msgDesc_ be the PropertyDescriptor { [[Value]]: _msg_, [[Writable]]: *true*, [[Enumerable]]: *false*, [[Configurable]]: *true* }.
1. Perform ! DefinePropertyOrThrow(_O_, *"message"*, _msgDesc_).
1. Return _O_.
The actual value of the string passed in step 2 is either *"%EvalError.prototype%"*, *"%RangeError.prototype%"*, *"%ReferenceError.prototype%"*, *"%SyntaxError.prototype%"*, *"%TypeError.prototype%"*, or *"%URIError.prototype%"* corresponding to which _NativeError_ constructor is being defined.
+The actual value of the string passed in step
For implementations that provide more accurate conversions than required by the rules above, it is recommended that the following alternative version of step 9.b.i be used as a guideline:
-For implementations that provide more accurate conversions than required by the rules above, it is recommended that the following alternative version of step
which returns the gcd in unary notation *"aaaaa"*.
Step 4 of the RepeatMatcher clears |Atom|'s captures each time |Atom| is repeated. We can see its behaviour in the regular expression
+Step
/(z)((a+)?(b+)?(c))*/.exec("zaacbbbcac")which returns the array
["zaacbbbcac", "z", "ac", "a", undefined, "c"]because each iteration of the outermost `*` clears all captured Strings contained in the quantified |Atom|, which in this case includes capture Strings numbered 2, 3, 4, and 5.
Step 2.b of the RepeatMatcher states that once the minimum number of repetitions has been satisfied, any more expansions of |Atom| that match the empty character sequence are not considered for further repetitions. This prevents the regular expression engine from falling into an infinite loop on patterns such as:
+Step
/(a*)*/.exec("b")or the slightly more complicated:
/(a*)b\1+/.exec("baaaac")The *"length"* property of the `concat` method is 1.
The explicit setting of the *"length"* property in step 6 is necessary to ensure that its value is correct in situations where the trailing elements of the result Array are not present.
+The explicit setting of the *"length"* property in step
The `concat` function is intentionally generic; it does not require that its *this* value be an Array object. Therefore it can be transferred to other kinds of objects for use as a method.
@@ -34133,11 +34133,11 @@The explicit setting of the *"length"* property of the result Array in step 11 was necessary in previous editions of ECMAScript to ensure that its length was correct in situations where the trailing elements of the result Array were not present. Setting *"length"* became unnecessary starting in ES2015 when the result Array was initialized to its proper length rather than an empty Array but is carried forward to preserve backward compatibility.
+The explicit setting of the *"length"* property of the result Array in step
The `slice` function is intentionally generic; it does not require that its *this* value be an Array object. Therefore it can be transferred to other kinds of objects for use as a method.
@@ -34290,8 +34290,8 @@Because non-existent property values always compare greater than *undefined* property values, and *undefined* always compares greater than any other value, *undefined* property values always sort to the end of the result, followed by non-existent property values.
Method calls performed by the ToString abstract operations in steps 5 and 6 have the potential to cause SortCompare to not behave as a consistent comparison function.
+Method calls performed by the ToString abstract operations in steps
The explicit setting of the *"length"* property of the result Array in step 19 was necessary in previous editions of ECMAScript to ensure that its length was correct in situations where the trailing elements of the result Array were not present. Setting *"length"* became unnecessary starting in ES2015 when the result Array was initialized to its proper length rather than an empty Array but is carried forward to preserve backward compatibility.
+The explicit setting of the *"length"* property of the result Array in step
The `splice` function is intentionally generic; it does not require that its *this* value be an Array object. Therefore it can be transferred to other kinds of objects for use as a method.
@@ -38129,11 +38129,11 @@The optional _reviver_ parameter is a function that takes two parameters, _key_ and _value_. It can filter and transform the results. It is called with each of the _key_/_value_ pairs produced by the parse, and its return value is used instead of the original value. If it returns what it received, the structure is not modified. If it returns *undefined* then the property is deleted from the result.
This function is the %JSONParse% intrinsic object.
The *"length"* property of the `parse` function is 2.
Valid JSON text is a subset of the ECMAScript |PrimaryExpression| syntax as modified by step 4 above. Step 2 verifies that _jsonString_ conforms to that subset, and step 6 asserts that that parsing and evaluation returns a value of an appropriate type.
+Valid JSON text is a subset of the ECMAScript |PrimaryExpression| syntax as modified by step
If an ECMAScript implementation has a mechanism for reporting diagnostic warning messages, a warning should be produced when code contains a |FunctionDeclaration| for which these compatibility semantics are applied and introduce observable differences from non-compatibility semantics. For example, if a var binding is not introduced because its introduction would create an early error, a warning message should not be produced.
During FunctionDeclarationInstantiation the following steps are performed in place of step 29:
-During FunctionDeclarationInstantiation the following steps are performed in place of step
During GlobalDeclarationInstantiation the following steps are performed in place of step 13:
-During GlobalDeclarationInstantiation the following steps are performed in place of step
During EvalDeclarationInstantiation the following steps are performed in place of step 7:
-During EvalDeclarationInstantiation the following steps are performed in place of step
During BlockDeclarationInstantiation the following steps are performed in place of step 3.a.ii.1:
-During BlockDeclarationInstantiation the following steps are performed in place of step
During BlockDeclarationInstantiation the following steps are performed in place of step 3.b.iii:
-During BlockDeclarationInstantiation the following steps are performed in place of step
The |Block| of a |Catch| clause may contain `var` declarations that bind a name that is also bound by the |CatchParameter|. At runtime, such bindings are instantiated in the VariableDeclarationEnvironment. They do not shadow the same-named bindings introduced by the |CatchParameter| and hence the |Initializer| for such `var` declarations will assign to the corresponding catch parameter rather than the `var` binding.
This modified behaviour also applies to `var` and `function` declarations introduced by direct eval calls contained within the |Block| of a |Catch| clause. This change is accomplished by modifying the algorithm of
Step 3.d.i.2.a.i is replaced by:
-Step
Step 7.d.ii.4.a.i.i is replaced by:
-Step
The following steps are inserted after step 3 of the
The following steps are inserted after step