return when desugaring to closures

[Brendan Eich]

On Oct 11, 2008, at 3:45 PM, Mark S. Miller wrote:

> On Sat, Oct 11, 2008 at 3:30 PM, Brendan Eich <brendan at mozilla.com>  
> wrote:
>> What's more, as discussed here and in TC39, repeated let  
>> declarations for
>> the same binding name within the same block should be allowed.  
>> Anything else
>> is user- and refactoring-hostile. So the non-initial let  
>> declarations for a
>> given name in the same block would be ignored.
>
> What if repeated let declarations constrain the same variable with
> different type-annotation-constraints?

The agreement from the May TC39 meeting was that the declarations  
implicit (:*) and explicit annotations must normalize to the same  
type, or there's an error.


> If we want to avoid the read-barrier, we should not hoist either const
> or let. If we are to consider not hoisting const, WE NEED TO DECIDE
> THIS NOW, before ES3.1 mandates a hoisting const.

A few messages back you nicely repeated the least-concepts/least- 
astonishment/most-symmetric case for hoisting to block top that has  
carried so far. I don't see how we can backtrack here. We'll flail hard.

Scheme has s-expression boundaries for every binding form. C-like  
languages do not, and that makes invisible start of scope boundaries  
for new bindings that appear mid-block (for C++ and languages that do  
not require declarations before statements). Indeed C++ has implicit  
copy constructions scoped within expressions. We don't want any of  
that, in my view. We want explicit forms that look different when they  
scope differently.

Either the read barrier must be swallowed (implemented using analysis  
or runtime checking), or else untyped let (as untyped var) can be used  
before set, resulting in undefined.

/be