-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Commit
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -695,9 +695,9 @@ <h1>Abstract Operations</h1> | |
<p>In order to facilitate their use in multiple parts of this specification, some algorithms, called <dfn>abstract operations</dfn>, 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 as _someValue_.operationName(_arg1_, _arg2_).</p> | ||
</emu-clause> | ||
|
||
<emu-clause id=sec-algorithm-conventions-production-associated-algorithms namespace=algorithm-conventions> | ||
<h1>Production-Associated Algorithms</h1> | ||
<p>Algorithms may be associated with productions of one of the ECMAScript grammars. Such algorithms are called <dfn>production-associated algorithms</dfn>. 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.</p> | ||
<emu-clause id=sec-algorithm-conventions-syntax-directed-operations namespace=algorithm-conventions> | ||
<h1>Syntax-Directed Operations</h1> | ||
<p>Algorithms may be associated with productions of one of the ECMAScript grammars. Such algorithms are called <dfn>syntax-directed operations</dfn>. 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.</p> | ||
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong. |
||
<p>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.</p> | ||
<p>Unless explicitly specified otherwise, all chain productions have an implicit definition for every algorithm that might be applied to that production's left-hand side nonterminal. The implicit definition simply reapplies the same algorithm name with the same parameters, if any, to the chain production's sole right-hand side nonterminal and then returns the result. For example, assume there is a production:</p> | ||
This comment has been minimized.
Sorry, something went wrong.
jmdyck
Collaborator
|
||
<emu-grammar> | ||
|
@@ -710,7 +710,7 @@ <h1>Production-Associated Algorithms</h1> | |
<emu-alg> | ||
1. Return the result of evaluating |StatementList|. | ||
</emu-alg> | ||
<p>Production-associated algorithms are referenced with a parse node by using the conventions on steps 1 and 3 in the following algorithm:</p> | ||
<p>Syntax-directed operations are referenced with a parse node by using the conventions on steps 1 and 3 in the following algorithm:</p> | ||
This comment has been minimized.
Sorry, something went wrong.
jmdyck
Collaborator
|
||
<emu-alg> | ||
1. Let _status_ be the result of performing ProductionAssociatedAlgorithm of |SomeNonTerminal|. | ||
2. Let _someParseNode_ be the parse of some source text. | ||
|
@@ -721,7 +721,7 @@ <h1>Production-Associated Algorithms</h1> | |
<!-- es6num="6.2.2.2" --> | ||
<emu-clause id="sec-runtime-semantics"> | ||
<h1>Runtime Semantics</h1> | ||
<p>Algorithms which specify semantics which occurs at runtime (i.e. after parsing, during execution) are called <dfn>Runtime Semantics</dfn>. Runtime semantics might be abstract operations or production-associated algorithms. Such algorithms always return a completion record.</p> | ||
<p>Algorithms which specify semantics which occurs at runtime (i.e. after parsing, during execution) are called <dfn>runtime semantics</dfn>. Runtime semantics might be abstract operations or syntax-directed operations. Such algorithms always return a completion record.</p> | ||
This comment has been minimized.
Sorry, something went wrong.
jmdyck
Collaborator
|
||
<emu-clause id="sec-implicit-completion-values"> | ||
<h1>Implicit Completion Values</h1> | ||
<p>The algorithms of this specification often implicitly return Completion Records whose [[Type]] is ~normal~. Unless it is otherwise obvious from the context, an algorithm statement that returns a value that is not a Completion Record, such as:</p> | ||
|
@@ -810,17 +810,17 @@ <h1>ReturnIfAbrupt Shorthands</h1> | |
<emu-alg> | ||
1. ReturnIfAbrupt(_someValue_.operationName()). | ||
</emu-alg> | ||
<p>Similarly, 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, the algorithm:</p> | ||
<p>Similarly, prefix `!` is used to indicate that the following invocation of an abstract or syntax-directed 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, the algorithm:</p> | ||
This comment has been minimized.
Sorry, something went wrong.
jmdyck
Collaborator
|
||
<emu-alg> | ||
1. Let _val_ be ! operationName(). | ||
</emu-alg> | ||
<p>is equivalent to the following algorithm steps:</p> | ||
<emu-alg> | ||
1. Let _val_ be operationName(). | ||
1. Assert: _val_ is never an abrupt completion. | ||
1. If _val_ is a Completion Record, let _val_ be _val_.[[Value]]. | ||
1. If _val_ is a Completion Record, set _val_ to _val_.[[Value]]. | ||
</emu-alg> | ||
<p>Production-associated algorithms for runtime semantics may also make use of this short-hand by placing `!` or `?` before the algorithm's name:</p> | ||
<p>Syntax-directed operations for runtime semantics may also make use of this shorthand by placing `!` or `?` before the invokation of the algorithm:</p> | ||
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong. |
||
<emu-alg> | ||
1. Perform ! ProductionAssociatedAlgorithm of |NonTerminal|. | ||
</emu-alg> | ||
|
It isn't the individual algorithms that are called 'syntax-directed operations': the algorithms (and productions) are the parts, and the SDO is the whole. How about starting with: "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."