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
_______________________________________________
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
