Skip to content

Commit

Permalink
Address review feedback
Browse files Browse the repository at this point in the history
  • Loading branch information
bterlson committed May 20, 2017
1 parent 87a1852 commit 6161792
Showing 1 changed file with 8 additions and 8 deletions.
16 changes: 8 additions & 8 deletions spec.html
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Copy link
@jmdyck

jmdyck May 21, 2017

Collaborator

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."

This comment has been minimized.

Copy link
@bterlson

bterlson May 21, 2017

Author Member

👍

This comment has been minimized.

Copy link
@bterlson

bterlson May 22, 2017

Author Member

2dea0b3 (can't push with crappy plane wifi :()

<p>When an algorithm is associated with a production alternative, the alternative is typically shown without any &ldquo;[ ]&rdquo; 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.

Copy link
@jmdyck

jmdyck May 21, 2017

Collaborator

Here, "algorithm" and "algorithm name" should be "syntax-directed operation" and "operation".

This comment has been minimized.

Copy link
@bterlson

bterlson May 22, 2017

Author Member

I went back and forth on this but I agree.

This comment has been minimized.

Copy link
@jmdyck

jmdyck May 22, 2017

Collaborator

If you move down the chain-production stuff, you could reword it in a way that I think is somewhat easier to follow: if the operation does not have an algorithm for that production, but the production is a chain production, then it is implicitly associated with an algorithm that simply [etc]

<emu-grammar>
Expand All @@ -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.

Copy link
@jmdyck

jmdyck May 22, 2017

Collaborator

"referenced" -> "invoked" would probably be better.

Maybe say something like: In a given invocation, the parse node is an instance of some production; in the simple case, the SDO associates that production with an algorithm, so that's the algorithm used to implement the invocation.

(It might make more sense to put the chain-production stuff (i.e., the non-simple case) after that.)

You also might want to point out that an SDO can have additional parameters, and then show how an invocation of such an SDO looks. (Mind you, there's a lot of variation in how it looks.)

<emu-alg>
1. Let _status_ be the result of performing ProductionAssociatedAlgorithm of |SomeNonTerminal|.
2. Let _someParseNode_ be the parse of some source text.
Expand All @@ -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.

Copy link
@jmdyck

jmdyck May 21, 2017

Collaborator

The first sentence is incorrect (or inconsistent with the rest of the spec): there are operations that we label "Static Semantics" that are invoked at 'runtime'.

The definition of 'runtime' ("after parsing, during execution") is unsatisfying, because the spec doesn't really define "execution". (E.g., if an implementation enforces early error rules after parsing, is that "during execution"?)

"Runtime semantics might be AOs or SDOs" sounds tentative and odd to me. How about: "Runtime semantics are defined by AOs and SDOs."

The last sentence is subject to issue #496.

This comment has been minimized.

Copy link
@bterlson

bterlson Jun 9, 2017

Author Member

I'm going to fix #496, but for now the above says:

<p>Algorithms which specify semantics that must be called at runtime are called <dfn>runtime semantics</dfn>. Runtime semantics are defined by abstract operations or syntax-directed operations. Such algorithms always return a completion record.</p>

This comment has been minimized.

Copy link
@jmdyck

jmdyck Jun 14, 2017

Collaborator

The "must" is odd, as it suggests a requirement on implementations, which is not what the sentence is saying. Maybe "... that are only called..." (or "... that are called only...").

It's also odd to say that semantics are called. You call an operation, you don't call semantics.

This comment has been minimized.

Copy link
@allenwb

allenwb Jun 14, 2017

Member

Perhaps: Algorithms which specify semantics that depend upon state that is only available at runtime are called ...

<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>
Expand Down Expand Up @@ -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.

Copy link
@jmdyck

jmdyck May 21, 2017

Collaborator

The structure of this section was:

  1. '?' for invocations of AOs.
  2. '!' for invocations of AOs.
  3. '!' and '?' for invocations of SDOs.

So adding "or syntax-directed [operation]" here mixes part of 3 into 2.

<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.

Copy link
@jmdyck

jmdyck May 21, 2017

Collaborator

"invokation" -> "invocation"

This comment has been minimized.

Copy link
@jmdyck

jmdyck May 21, 2017

Collaborator

"algorithm" -> "operation"

<emu-alg>
1. Perform ! ProductionAssociatedAlgorithm of |NonTerminal|.
</emu-alg>
Expand Down

0 comments on commit 6161792

Please sign in to comment.