return when desugaring to closures
Brendan Eich
brendan at mozilla.com
Sat Oct 11 16:01:30 PDT 2008
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
More information about the Es-discuss
mailing list