Block scoping and redeclarations

Andreas Rossberg rossberg at google.com
Wed Aug 24 02:01:33 PDT 2011


On 23 August 2011 19:14, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>
> On Aug 23, 2011, at 5:31 AM, Andreas Rossberg wrote:
>
>> We are currently in the process of implementing block scoping for V8
>> (http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings).
>
> The wiki page spec. is neither complete nor up to date so I wouldn't depend too much on what it says.
>
> I'm in the process of writing the actual draft specification for block scoped declaration and expect to have it ready for review in advance of the next TC39 meeting.  It's up to you, but it might be more economical to put off your implementation for a couple weeks until that spec. is ready

That's OK, we are aware that the spec is not finalized yet. For most
part, the semantics is rather obvious, and we try to avoid putting too
much work into aspects that aren't clear yet (such as the global
scope).

>> Brendan and Dave suggest that certain combinations of `let' and `var'
>> should be an error (more precisely, a syntax error, I assume).
>> However, there are various possibilities to interpret this. Assume
>> that each line in the following is a function scope:
>>
>> { let x; var x }  // 1a
>> { var x; let x }  // 1b
>>
>> { let x; { var x } }  // 2a
>> { var x; { let x } }  // 2b
>>
>> { { let x } var x }    // 3a
>> { { var x } let x }    // 3b
>>
>> { { let x } { var x } }  // 4a
>> { { var x } { let x } }  // 4b
>>
>> 1a-2a should clearly be errors. Same for 3b arguably, because the var
>> is hoisted to the same scope as the let. In 2b, 3a, and 4a/b, a var is
>> shadowed by a let, which isn't a problem in principle. OTOH, strictly
>> speaking, at least 3a and 4a actually introduce a "var-declaration
>> that has already been shadowed by a let-declaration" (Dave's words).
>
> I think the July meeting discussion covers all of these cases and I agree that 1a,1b, 2a,3b are errors and 2b,3a,4a,4b are not.

Hm, I'm not sure I remember that we discussed this particular aspect
in detail in July. Sorry if I missed something.

> I don't think Dave's quote applies to 3a and 4a.  The var declaration is always logically hoisted to the top of the function so it is already in place before the let block shadows it.  Another way to look at it is that within any scope contour, the same name can not be used within multiple declarations (except for multiple vars for the same name) that occur or are hoisted into that contour.  The order of the multiple declaration doesn't really matter.

Oh, but that description does not cover Dave's exact example, which actually was

{ { let x; { var x } } }

Here, the var is hoisted across the let's scope, but doesn't end up in
the same scope. And we clearly want to rule that out, too. But then,
you also want to properly distinguish this case from, say

{ { { let x } { var x } } }

So, while I see what you tried to say there, the fact that it didn't
quite nail it reinforces my feeling that any actual rule might be more
complicated to specify accurately than worthwhile.

>> * It is a syntax error if a given identifier is declared by both a
>> let-declaration and a var-delaration in the same function. (And
>> similarly, for const vs. var, or function vs. var -- the latter being
>> an incompatible change for the global scope, but it seems like we may
>> abolish that anyway.)
>
> I'm not sure that this actually simplifies anything. We still need hoisting rules for let and we still need something like the multiple declaration rules above so just is yet another rule that has to be specified, implemented, and remembered by users. If we think cases such as 3a and 4a are real bug farms then maybe the additional rule carries its weight.  But I'm not sure that we have all that much of a hazard even without it.  I just don't expect to see much code that looked like 3a or 4a.

I'm not sure I follow. It's not an additional rule -- the way I view
it it is a rule that replaces a (set of) more complicated rule(s). And
if we don't expect the cases in question to show up often, then
doesn't that seems rather like an argument for the simplification than
against it?

That's not to say that I couldn't live with more fine-grained rules, I
just don't consider them worthwhile. Ultimately, we want to morally
deprecate "var" for Harmony mode, so introducing too many extra rules
around it seems a bit unjustified, unless there is a very good reason.

Thanks,
/Andreas


More information about the es-discuss mailing list