return when desugaring to closures

Brendan Eich brendan at mozilla.com
Tue Oct 14 13:27:34 PDT 2008


On Oct 14, 2008, at 11:19 AM, Waldemar Horwat wrote:

> Brendan Eich wrote:
>>> function f() {
>>> x = 15;
>>> ...
>>> var t = some_runtime_expression;
>>> ...
>>> var x:t = ...
>>> }
>>>
>>> that ought to fail to compile.
>>
>> The assignment to x in that temporal dead zone before t's initializer
>> has been evaluated.
>>
>> Why is this different if you s/var x/let x/?
>
> Ah, ok.  That's good news!  For a long time I wanted to make  
> statically detectable uses of a variable before its let or const  
> declaration runs to be compile-time errors.  You can't detect all of  
> them due to closures, but you can detect most in practice.  I'm glad  
> you agree.

But before you change the assumptions of our argument, what was  
hazardous about that example with var, but not with let, assuming no  
static analysis requirement to flag an error? Or did I misunderstand  
your point?

I mentioned in email to you this paper:

http://portal.acm.org/citation.cfm?id=197331

I'm not so worried about analyses that require computing dominance  
relations within a function. Computing name uses and intersecting  
scopes across functions are a different order of work (implementation  
complexity). Advanced implementations are already doing such things  
(where with and eval don't create hopeless ambiguities) but the spec  
should not require anything approaching whole-program or all-nesting/ 
nested-functions analyses.

Other implementors on the list should sound off.

/be



More information about the Es-discuss mailing list