return when desugaring to closures
brendan at mozilla.com
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 mozilla.com>
>> 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
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
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