----------------------------------------
In 14.1 "Function Definitions":
14.1 / Syntax / prod 6 (FormalsList) / rhs 1:
FormalParameter[?Yield]
Insert "?GeneratorParameter", as in rhs 2.
(Why would the first FormalParameter in a FormalsList
be different from the others?)
----------------------------------------
In 14.1.12 "Static Semantics: ReferencesSuper":
14.1.12 / group 4 / production + step 1:
FormalParameters : FormalParametersList
1. Return FormalParametersList Contains super.
s|Parameters|Parameter|
----------------------------------------
In 14.2.4 "Static Semantics: CoveredFormalsList":
14.2.4 / group 2 / production / rhs 3+4:
( ... IdentifierName )
( Expression , ... IdentifierName )
s|IdentifierName|BindingIdentifier|
----------------------------------------
In 14.2.8 "Runtime Semantics: IteratorBindingInitialisation":
14.2.8 / group 2 / step 2:
Return the result of performing IteratorBindingInitialisation of /formals/
with arguments /value/ and /environment/.
s|value|iterator|
----------------------------------------
In 14.2.10 "Runtime Semantics: Evaluation":
14.2.10 / group 1 / step 4:
... performing the FunctionCreate abstract operation with arguments Arrow, ...
Change "Arrow" to sans-serif.
----------------------------------------
In 14.3.8 "Runtime Semantics: DefineMethod":
14.3.8 / step 5:
... performing the FunctionCreate abstract operation with arguments Method, ...
Put "Method" in sans-serif.
----------------------------------------
In 14.3.9 "Runtime Semantics: PropertyDefinitionEvaluation":
14.3.9 / group 3 / step 6:
... performing the FunctionCreate abstract operation with arguments Method, ...
Put "Method" in sans-serif.
14.3.9 / group 4 / step 5:
... performing the FunctionCreate abstract operation with arguments Method, ...
Put "Method" in sans-serif.
----------------------------------------
In 14.4.11 "Runtime Semantics: EvaluateBody":
14.4.11 / group 2 / step 1:
Let /G/ be the result of ObjectCreate(*%*GeneratorPrototype*%*, ... ).
De-bold percents.
----------------------------------------
In 14.4.13 "Runtime Semantics: PropertyDefinitionEvaluation":
14.4.13 / group 1 / step 6:
... the GeneratorFunctionCreate abstract operation with arguments Method, ...
Put "Method" in sans-serif.
----------------------------------------
In 14.5.4 "Static Semantics: Contains":
14.5.4 / group 1 / step 4:
Return the result of Contains for /ClassHeritage/ with argument /symbol/.
'Contains' is normally invoked via an infix notation.
Change to:
... the result of /ClassHeritage/ Contains /symbol/
----------------------------------------
In 14.5.9 "Static Semantics: PrototypeMethodDefinitions":
In 14.5.13 "Static Semantics: StaticMethodDefinitions":
As defined, each of these returns a List of ClassElements, but section
14.5.15 assumes that they each return a list of MethodDefinitions.
On the appropriate step, change /ClassElement/ to:
the /MethodDefinition/ of /ClassElement/
----------------------------------------
In 14.6.1 "Static Semantics: InTailPosition(nonterminal) Abstract Operation":
For a semantic rule that returns a boolean, the name usually begins with
"Is" or "Has". Rename to "IsInTailPosition" ?
This algorithm has no preamble.
14.6.1 / step 1:
Assert: /nonterminal/ is a parsed grammar production.
The phrase "parsed grammar production" is odd.
Instead, "parse node" (as in Table 26) would be more normal.
(And "parse-tree node" probably even more so.)
Likewise, change /nonterminal/ to /node/ throughout the algorithm.
----------------------------------------
In 14.6.2 "Static Semantics: HasProductionInTailPosition":
A better name might be "HasCallInTailPosition".
This is the only place in the spec where a semantic routine has its "header"
in one section and then has its production/algorithm groups set out in
subsections. It's just odd.
Rename parameter /nonterminal/ to /node/ (or maybe /expr/ or /callExpr/).
----------------------------------------
In 14.6.2.1 "Statement Rules":
14.6.2.1 / group 5 / production 4:
The production-recap for LabelledStatement
does not match its defining production in 13.12 / Syntax.
14.6.2.1 / group 13 (the last one) / step 1:
Return HasProductionInTailPosition of /Finally/ with argument /nonterminal/.
s|Finally|Block|
----------------------------------------
In 14.6.2.2 "Expression Rules":
14.6.2.2 / group 7 / step 1:
If this /MemberExpression/ is /nonTerminal/, then return *true*.
De-capitalize the "T" in "nonTerminal".
14.6.2.2 / group 8 / step 1:
If this /NewExpression/ is /nonterminal/, then return *true*.
I'm doubtful that this condition could ever be satisfied, because
I don't see anywhere that HasProductionInTailPosition is invoked
with a NewExpression as the argument.
----------------------------------------
In 14.6.3 "Runtime Semantics: PrepareForTailCall":
Add "()" to the section title, so it's clearer that the operation doesn't
have any parameters.
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Some of these were fixed in rev23, but most remain in rev24.
14.2.8 has moved to 14.2.15,
14.2.10 to 14.2.17.
Regarding the organization of the tail call rules: Yes this is a different style of organization, but it seems to work well for tail calls which is a pretty self contained part of the the overall specification. So, I'm not going to change it.
Some reviewers would prefer that everything was reorganized more like the tail call section, but thats also not going to happen. At least not in this edition.
I thought about renaming HasPropductionInTailPosiition, but decided against it. It isn't looking for any call, it is looking for the specific a"production" that is passed in as the argument.
Also, while "production" isn't quite right technically (we're really talking about parse nodes) the ES6 spec. has, so far, gotten away with fuzzing the distinction between grammar productions and the parse trees produced by parsing using those productions. I think we can continue to be fuzzy in that regard here.
Otherwise, all fixed in rev25 editor's draft.
(In reply to comment #2)
> Regarding the organization of the tail call rules: Yes this is a different
> style of organization, but it seems to work well for tail calls which is a
> pretty self contained part of the the overall specification. So, I'm not
> going to change it.
>
> Some reviewers would prefer that everything was reorganized more like the
> tail call section, but thats also not going to happen. At least not in this
> edition.
Actually, I don't mind that all the HasProductionInTailPosition rules are grouped together, or that most other operations have their rules spread throughout the spec. Either/both is fine with me. I'm just pointing out that, normally, a set of rules appears in a section whose header gives the name of the semantic operation being defined, followed by its parameters. Here, you have to go up another level to get that info.
> Also, while "production" isn't quite right technically (we're really talking
> about parse nodes) the ES6 spec. has, so far, gotten away with fuzzing the
> distinction between grammar productions and the parse trees produced by
> parsing using those productions.
Yes, I've been meaning to raise a bug on that point. (But I figured I might as well wait until the technical changes were more or less done.)
confirmed fixed except for what I re-raised as Bug 2951, and the stuff about "parsed grammar production" and "nonterminal" that I intend to raise more generally at some point.