return when desugaring to closures

Brendan Eich brendan at mozilla.com
Mon Oct 13 16:09:51 PDT 2008


On Oct 13, 2008, at 4:01 PM, Waldemar Horwat wrote:

> Brendan Eich wrote:
>> If using an uninitialized let binding is an error, then hoisting is
>> pointless except to make the statements between start of block and  
>> the
>> let declaration a dead zone for the binding name. This fits the
>> ancient, weak but not entirely worthless post-hoc rationale for var
>> hoisting (to avoid confusion among novice or inexperienced  
>> programmers
>> by making many scopes, each implicitly opened by var), but it's not
>> particularly useful.
>
> This was our agreement from the ES4 days.  It's very useful, in that  
> it allows mutually recursive lambdas.

For function bindings, yes, of course -- but we were talking about let  
bindings (I thought). For let (there is no 'let function') bindings,  
how? Could you give an example?


>> What's more, as discussed here and in TC39, repeated let declarations
>> for the same binding name within the same block should be allowed.
>
> You can't do that in ES-Harmony.  There is no way to tell if the two  
> let declarations have the same type.

There has to be a way to answer the question "are these two terms the  
same type" at run-time.


> For orthogonality you'd also need to allow multiple const  
> declarations within the same scope, and I just don't want to go there.

I don't agree -- const and let are different keywords, they obviously  
differ in read-only vs. writable binding. They could differ otherwise.


>> Anything else is user- and refactoring-hostile. So the non-initial  
>> let
>> declarations for a given name in the same block would be ignored.
>
> This is loaded language, but I can't tell how requiring there to be  
> a unique point of definition for a const or let is user-hostile.

My words were about let, not const. If let is the new var, then you  
either accept that re-declaration in the same block (usually function  
body) of the same name via var is common for good reason, and allow  
let to be used instead; or you raise the migration tax.

I do not mean to over-load the language, but we've seen a lot of code  
that redeclares using var (e.g. for (var i...) in adjacent for loops).  
We tried making a strict warning (error console spew) for  
redeclarations of same kind (var vs. var) four years ago (IIRC --  
Firefox 1 betas) and felt the heat from developers. We fell back on  
mixed var vs. function (const vs. anything is an error of course).

People on this list have argued similarly based on refactoring and var  
hoisting.

It may be that the migration tax must rise here, but I'd like to know  
why type annotations can't be equated at runtime.

/be


More information about the Es-discuss mailing list