return when desugaring to closures

Brendan Eich brendan at mozilla.com
Mon Oct 13 18:41:46 PDT 2008


On Oct 13, 2008, at 6:08 PM, Waldemar Horwat wrote:

> Brendan Eich wrote:
>>> Because presumably the "let x:t" became "var x:t" and var can't have
>>> types?
>>
>> Why can't var have a type annotation?
>
> Because a function can have many var declarations for the same  
> variable and because you can use the variable before any of the var  
> declarations are evaluated.  You can work out the implications  
> easily enough.  This has been brought up at meetings before.

Of course, ES4 had var x:t all over, but as you noted, different rules  
for evaluating t. Still, with new syntax comes the opportunity for  
reformed semantics, including restrictions on any "bad" var abusages  
we would like to move away from.

So my question remains (amended to be clear about what is the same):  
why does this mean we cannot equate let and var scope at the top  
level? I'm not talking about allowing them to mix in bad ways, or mix  
at all (see below). I'm talking about not having an implicit block  
around top-level function and global code.


>  You wrote that you'd like let to become var (and unlike let as used  
> within an independent block) if used at the top level of a function:

Ok, sorry for being unclear. I do not mean to translate top-level  
'let' to 'var' and free let bindings from necessary restrictions. I do  
mean that let binds in the variable object, and let usage restricts  
other usage.

We can forbid mixed var x and let x at top level. We can require the  
same single definition for any let x at any level. We can forbid  
arguments usage if arguments[i] could alias a let binding, since let  
is new (along with rest and optional parameters to enable arguments  
deprecation).

But must we have an implicit block around programs and function bodies  
that contain let declarations, distinct from the variable scope  
(object)?


> What did you mean by "had better fail to compile"?  Other than the  
> type annotation, there is nothing about
>
> 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/?

/be



More information about the Es-discuss mailing list