On Oct 11, 2008, at 2:55 PM, Mark S. Miller wrote: > On Sat, Oct 11, 2008 at 2:42 PM, Brendan Eich <[EMAIL PROTECTED]> > 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. /be _______________________________________________ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss