for var expression bindings and lexical declarations

[leobalter]

I'd like to clarify something I've been reading from the specs, and verify if there is any action necessary.

for productions like for ( var f in [] ) { ... } and for (var f; ; ) { ... } we have the f binding name added to VarDeclaredNames of the for Statement. This happens from Static Semantics.

If it's a BlockStatement, we might encounter the Early SyntaxError when a lexical declared name also occurs in the VarDeclaredNames of the respective StatementList. Basically: { let f; var f; }.

Considering in the examples above for for, where bindings are appended to VarDeclaredNames, should this error also be observed?

Currently no engine observes the SyntaxError for cases like: for (var f in []) { let f; } and for (var f; ; ) { let f }.

So the possible solutions are:

1. Am I missing any text in the spec saying this SyntaxError won't happen to names appended to VarDeclaredNames?
2. We enforce the SyntaxError to be consistent and throw a SyntaxError also for names added to VarDeclaredNames and then redeclared as lexical names in the respective statement list? We add tests and expect all engines to fix this?
3. We might add a text saying the Early Error doesn't observe names appended to the respective VarDeclaredNames from extensive productions. All browsers already comply to this behavior.

Thanks

[bakkot]

Considering in the examples above for for, where bindings are appended to VarDeclaredNames, should this error also be observed?

If I'm reading the spec correctly, the error refers to "the VarDeclaredNames of StatementList", whereas the static semantics VarDeclaredNames for for-in only puts the declaration in the VarDeclaredNames of the for-in statement itself. So it wouldn't be an error.

Just in case it's the source of the confusion: Lists in the spec are effectively copied rather than being mutated when they're passed between abstract operations. That is, when 13.7.5.7 says "Append to names the elements of the VarDeclaredNames of Statement" it doesn't actually modify the VarDeclaredNames of Statement; rather, it creates a new list which is the concatenation of names and the VarDeclaredNames of Statement. So the VarDeclaredNames of the block does not start containing the names introduced by the for statement.

[leobalter]

Thank you so much for the clarification! This is what I was looking for and helped my sanity while reading the specs alone.

…

On Mon, Dec 3, 2018 at 3:11 PM Kevin Gibbons ***@***.***> wrote: Considering in the examples above for for, where bindings are appended to VarDeclaredNames, should this error also be observed? If I'm reading the spec correctly, the error <https://tc39.github.io/ecma262/#sec-block-static-semantics-early-errors> refers to "the VarDeclaredNames of StatementList", whereas the static semantics <https://tc39.github.io/ecma262/#sec-for-in-and-for-of-statements-static-semantics-vardeclarednames> VarDeclaredNames for for-in only puts the declaration in the VarDeclaredNames of the for-in statement itself. So it wouldn't be an error. Just in case it's the source of the confusion: Lists in the spec are effectively copied rather than being mutated when they're passed between abstract operations. That is, when 13.7.5.7 says "Append to names the elements of the VarDeclaredNames of Statement" it doesn't actually modify the VarDeclaredNames of Statement; rather, it creates a *new* list which is the concatenation of names and the VarDeclaredNames of Statement. So the VarDeclaredNames of the block does not start containing the names introduced by the for statement. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1365 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASYkeBT6-CXltueq26w3GXvIJfjupABks5u1YVkgaJpZM4Y_Tbr> .

[jmdyck]

@bakkot:

Lists in the spec are effectively copied rather than being mutated when they're passed between abstract operations.

Hm. My first guess would be that there aren't any cases where it actually makes a difference. But if there are such cases, I would not expect copy-on-pass. See Algorithm Conventions: aliases are reference-like, and if you don't want that, explicitly make a copy. (It's not talking about parameters specifically, but I'd expect them to behave the same as "let" aliases.)

That is, when 13.7.5.7 says "Append to names the elements of the VarDeclaredNames of Statement" it doesn't actually modify the VarDeclaredNames of Statement;

True, but there shouldn't really be any question of that.

rather, it creates a new list which is the concatenation of names and the VarDeclaredNames of Statement.

No, the List that names refers to is modified (by appending the elements of the VarDeclaredNames of Statement).

So the VarDeclaredNames of the block does not start containing the names introduced by the for statement.

I have a feeling you've misread the spec. Note that it says:
Append to _names_ the elements of X.
and not:
Append _names_ to the elements of X.

(The things you're saying would be appropriate if it said the latter, but not when it says the former.)

[bakkot]

@jmdyck:

Ah, I did indeed miss that it says "Append to names the elements of X" rather than the other way around.

So when I said "it doesn't actually modify the VarDeclaredNames of Statement", I should have said "it doesn't actually modify the BoundNames of VariableDeclarationList". The question is premised on "the VarDeclaredNames of Statement" changing, so I assume Leo misread that line the same way I did.

Anyway, I think the intended way of understanding the spec is that "the BoundNames of VariableDeclarationList" is implicitly a new invocation of the BoundNames abstract operation which returns a list which does not share identity with the returned value of any other such invocation, so that when one consumer of that abstract operation appends to it, that will not be seen by other consumers which refer to it. (As opposed to a sort of stateful variable. If I understand correctly, Leo's was confused because he thought "VarDeclaredNames of Statement" was just such a stateful variable.)

I believe this is entirely equivalent to "lists are copied rather than being mutated when being passed between abstract operations". I find it a little easier to explain in terms of lists being copied.

---

To give a code example: I assume Leo was reading the spec as if it said

let BoundNamesOfVariableDeclarationList = (function(){
  // some algorithm which is equivalent to
  return ['x'];
})();

let VarDeclaredNamesOfBlockStatement = (function(){
  // some algorithm which is equivalent to
  return [];
})();

let VarDeclaredNamesOfForStatement = (function(){
  let names = BoundNamesOfVariableDeclarationList;
  BoundNamesOfVariableDeclarationList.push(...VarDeclaredNamesOfBlockStatement);
  return names;
})();

whereas it is instead meant to be interpreted as

let BoundNamesOfVariableDeclarationList = function(){
  // some algorithm which is in this case equivalent to
  return ['x'];
};

let VarDeclaredNamesOfBlockStatement = function(){
  // some algorithm which is in this case equivalent to
  return [];
};

let VarDeclaredNamesOfForStatement = function(){
  let names = BoundNamesOfVariableDeclarationList();
  BoundNamesOfVariableDeclarationList.push(...VarDeclaredNamesOfBlockStatement());
  return names;
};

yes?

(My interpretation is a third option, which is the same as the first sample except that it's more like let names = copy(BoundNamesOfVariableDeclarationList), which has the same semantics as the second sample.)

[leobalter]

@bakkot One thing that I got from @jugglinmike in a private chat is the fact I'm not looking at the actual VarDeclaredNames of StatementList. The spec text gives an idea it's only observed the semantics for that very production from StatementList, limiting anything added otherwise.

Block, Static Semantics: Early Errors
   - It is a Syntax Error if any element of the LexicallyDeclaredNames of
  StatementList also occurs in the VarDeclaredNames of StatementList.

[leobalter]

I got an interesting example were the append happens as well:

{ let f; { var f; } }

The VarDeclaredNames list of the outer block contains the items from the VarDeclaredNames list of the inner block. These items are appended.

If some for-var will append names to the block, it sounds the idea is to have lexical names conflicting with the vars anyway. In anyway, for (var f;;) { let f; } should not be allowed from parsing. Question is: is it worth the hassle? My only reasoning is consistency.

[ajklein]

@leobalter I'm not sure I'm following you properly. But I'd like to understand the confusion. Taking the two examples from your most recent message:

1. { let f; { var f; } } is indeed an error due to the appending, and the early error link @bakkot linked to. And leaving the spec language aside, it's conceptually an error since it would need to "hoist" the var over the let.
2. for (var f;;) { let f; } doesn't look to me like an error, conceptually: the let binding is contained to the block, so "cleanly" shadows the var binding, and the var is visible outside the block as expected (it doesn't have to be hoisted over anything. As for the spec, I don't see why it should be an error; the rule about not mixing lexical and var-declared names is specific to Block. If you think the spec does say this should be disallowed, can you link to the specific section you think is responsible for generating this error?

[leobalter]

Thanks, @ajklein! I'm still on the error for blocks... https://tc39.github.io/ecma262/#sec-block-static-semantics-early-errors

I believe I overwhelmed myself with confusion about this today and I'll give it review again tomorrow morning. From your answer, it seems I just misread the text anyway. I appreciate everyone's help here!