return when desugaring to closures

Brendan Eich brendan at
Sat Oct 11 15:30:56 PDT 2008

On Oct 11, 2008, at 2:55 PM, Mark S. Miller wrote:

> On Sat, Oct 11, 2008 at 2:42 PM, Brendan Eich <brendan at>  
> wrote:
>> We've discussed making use-before-set a strict error, but we've
>> avoided it. The initialiser is not mandatory, and we do not wish to
>> impose costly analysis on small implementations.
> Since "const" use-before-set is an unconditional error (i.e., not
> dependent on strictness), implementations already have to pay for a
> read-barrier mechanism. Since we'd like to support
> type-annotation-constraints on initialized let variables, I think
> initialized let variables should have an unconditional read barrier as
> well.

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.

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.

This leaves efficiency as a concern. If implementations do not do the  
analysis required to catch use before set at compile time, then let as  
well as const pays the read barrier price. It's non-trivial. Today let  
(and var in the absence of eval) can be optimized to use a "read" in  
the VM, possibly even a load instruction -- no getter barrier  
required. Whatever the GC write barrier cost, reads dominate and this  
is a significant savings.

On the other hand, computing SSA including dominance relations while  
parsing (in one pass) is possible so long as we do not add goto to the  
language. So maybe the analysis is acceptable to modern  
implementations, which are increasingly sophisticated.

Still, it is not yet agreed that let use before set shall be an error.  
It certainly is not the case for var, and working code counts on the  
undefined default initial value.


More information about the Es-discuss mailing list