Ch.13, cumulative bugs & suggestions
[Note: this is against Rev. 23, some things might have been fixed or changed already.]
TECHNICAL ISSUES
13.2.1: there needs to be a definition of VarDeclaredNames for LexicalDeclaration (used via Statement)
13.2.2: dito for VariableStatement
13.6.3.2, 1st case, step 2: "first" -> "second" and "second" -> "third"
13.6.4.1, 1st, case, 3rd bullet: "can be statically determined" is too imprecise, see above
13.6.4.1, 2nd case, 2nd bullet: Why does a similar restriction not also apply in the first case?
13.9: doesn't this need to define that 'return' is a syntax error if this appears outside a function?
13.11.5, 1st case, step 2: "CaseClause items" -> "CaseClause items in CaseClauses_opt"
13.12, Note: The comment about the initial 'empty' element in label sets seems inaccurate.
13.14.1, 1st bullet: this restriction is unnecessary, and inconsistent with what we decided on for function parameters
SUGGESTIONS
13.1.5: rename to TopLevelLexicalDeclarations, for consistency with LexicalDeclarations function
13.1.11, step 4: "in list order" -- this should not matter here
13.1.11: why have the separate loop? It seems none of this can have any other side effect, so order doesn't matter, and you can invoke Create and Instantiate immediately in the same loop
13.2.2.3, 4th case: a variation of step 4 and its substeps for setting "name" reappears in various places. It might make sense to factor this out into an algorithm like SetNameIfFunction(value, string)
13.4.1: aren't steps 3 and 4 equivalent to simply returning value?
13.6.1.2: perhaps swap steps 2.b and 2.c
13.6.2.2: dito with steps 2.f and 2.g
13.6.3.2, 3rd case, step 9: Is the special-casing of const necessary? Why not simply copy all of the env in CreatePerIterationEnv? AFAICT, the difference is not observable.
13.6.3.3: perhaps swap steps 4.c and 4.d
13.14.3, step: fold this into BindingInitialization
TYPOS & FORMATTING
13.0: weird section numbering?
13.1.11, Note: "each block scoped variable, constant or function" -- or class
13.2.1, Note: "[-A] let and const declarations"
13.2.2.2, Note: "This is the case for var statements [+and] formal parameter lists"
13.2.2.3, 4th case, Note: "step 3" -> "step 5"; also, formatting of 'value'
13.6.1.2, step 1: formatting of 'undefined'
13.6.2.2, step 1: dito
13.6.3.2, 3rd case, step 9: "perI[n]terationList"
13.6.4.3, 3rd case: formatting of 'in' in production
13.11.4, 3rd case, step 3: formatting of DefaultClause
(In reply to comment #0)
> 13.2.1: there needs to be a definition of VarDeclaredNames for
> LexicalDeclaration (used via Statement)
> 13.2.2: dito for VariableStatement
This was fixed in VariableStatement in rev25
But, I don't see a path where applying VarDeclaredNames to Statement can reach a LexicalDeclaration. What did you have in mind?
(In reply to comment #0)
>
> 13.6.4.1, 2nd case, 2nd bullet: Why does a similar restriction not also apply
> in the first case?
>
Because in first case (for (expr in ...) the loop head can't create any lexical bindings. The rule in question is intended to issue an error for cases like this:
for (let x of foo) {var x};// can't hoist a var declaration over a like-named let declaration.
Were you thinking of something else?
(In reply to comment #1)
> (In reply to comment #0)
>
> > 13.2.1: there needs to be a definition of VarDeclaredNames for
> > LexicalDeclaration (used via Statement)
> > 13.2.2: dito for VariableStatement
>
> This was fixed in VariableStatement in rev25
>
> But, I don't see a path where applying VarDeclaredNames to Statement can reach
> a LexicalDeclaration. What did you have in mind?
Hm, me neither. I'm not sure what I had in mind (and can't find my respective notes anymore). Let's just assume I was confused. :)
(In reply to comment #3)
> (In reply to comment #1)
> > (In reply to comment #0)
> >
> > > 13.2.1: there needs to be a definition of VarDeclaredNames for
> > > LexicalDeclaration (used via Statement)
> > > 13.2.2: dito for VariableStatement
> >
> > This was fixed in VariableStatement in rev25
> >
> > But, I don't see a path where applying VarDeclaredNames to Statement can reach
> > a LexicalDeclaration. What did you have in mind?
>
> Hm, me neither. I'm not sure what I had in mind (and can't find my respective
> notes anymore). Let's just assume I was confused. :)
On the other hand, VarDeclaredNames _is_ explicitly defined for {Function,Generator,Class}Declaration. How are they reachable?
(In reply to comment #2)
> (In reply to comment #0)
> >
> > 13.6.4.1, 2nd case, 2nd bullet: Why does a similar restriction not also apply
> > in the first case?
> >
> Because in first case (for (expr in ...) the loop head can't create any lexical
> bindings. The rule in question is intended to issue an error for cases like
> this:
>
> for (let x of foo) {var x};// can't hoist a var declaration over a like-named
> let declaration.
>
> Were you thinking of something else?
Sorry, "first case" was misleading, what I meant were C-style for-loops. That is, why is
for (let x; ;) {var x}
not restricted in the same manner? Or am I missing something?
(In reply to comment #4)
>
> On the other hand, VarDeclaredNames _is_ explicitly defined for
> {Function,Generator,Class}Declaration. How are they reachable?
It's needed for FunctionDeclaration to support an Annex B extensions that makes
label: function f() {};
legal for non-strict code.
As far as I can tell it is not needed for ClassDeclaration.
It is only needed for GeneratorDeclarations if the Annex B LabelledStatement extensions is also applied to them. Current I only define it for FunctionDeclarations because GeneratorDeclarations aren't a legacy feature.
(In reply to comment #5)
>
> Sorry, "first case" was misleading, what I meant were C-style for-loops. That
> is, why is
>
> for (let x; ;) {var x}
>
> not restricted in the same manner? Or am I missing something?
Right, that restriction is also need for those cases. Fixed.
(In reply to comment #0)
>
> 13.9: doesn't this need to define that 'return' is a syntax error if this
> appears outside a function?
No, statement list is parametrized such that ReturnStatement is only allowed in certain contexts.
>
> 13.14.1, 1st bullet: this restriction is unnecessary, and inconsistent with
> what we decided on for function parameters
Disagree
>
>
> SUGGESTIONS
>
> 13.1.5: rename to TopLevelLexicalDeclarations, for consistency with
> LexicalDeclarations function
already done
> 13.1.11, step 4: "in list order" -- this should not matter here
ok
> 13.1.11: why have the separate loop? It seems none of this can have any other
> side effect, so order doesn't matter, and you can invoke Create and Instantiate
> immediately in the same loop
merged loops
>
> 13.2.2.3, 4th case: a variation of step 4 and its substeps for setting "name"
> reappears in various places. It might make sense to factor this out into an
> algorithm like SetNameIfFunction(value, string)
Plausible, but there is enough local variation to make it non-trivial. I'm disinclined to put the time into it.
>
> 13.4.1: aren't steps 3 and 4 equivalent to simply returning value?
yes, fixed
>
> 13.6.1.2: perhaps swap steps 2.b and 2.c
> 13.6.2.2: dito with steps 2.f and 2.g
ok
> 13.6.3.2, 3rd case, step 9: Is the special-casing of const necessary? Why not
> simply copy all of the env in CreatePerIterationEnv? AFAICT, the difference is
> not observable.
The current formulation simplifies CreatPerIterationEnvironment such that it doesn't have to deal with creating both mutable and immutable bindings.
> 13.6.3.3: perhaps swap steps 4.c and 4.d
ok
>
> 13.14.3, step: fold this into BindingInitialization
This would be purely cosmetic and the cascading effects of this are bigger than what I want to deal with at this time.
>
>
> TYPOS & FORMATTING
>
> 13.0: weird section numbering?
yes, it's intentional
> 13.1.11, Note: "each block scoped variable, constant or function" -- or class
ok
> 13.2.1, Note: "[-A] let and const declarations"
ok
> 13.2.2.2, Note: "This is the case for var statements [+and] formal parameter
> lists"
ok
> 13.2.2.3, 4th case, Note: "step 3" -> "step 5"; also, formatting of 'value'
ok
> 13.6.1.2, step 1: formatting of 'undefined'
> 13.6.2.2, step 1: dito
fixed
> 13.6.3.2, 3rd case, step 9: "perI[n]terationList"
fixed
> 13.6.4.3, 3rd case: formatting of 'in' in production
> 13.11.4, 3rd case, step 3: formatting of DefaultClause
fixed
fixed (or not) as noted above in rev26 editor's draft
open Bug 3005 relating to disagreement on whether
try {} catch(x) {let x};
should be an error
in rev26 draft