return when desugaring to closures

[Brendan Eich]

Followup to discuss some open issues from the thread, evident in the  
message cited below:

1. Unifying var scope and let scope at top level of a function could  
be done, with tolerable restrictions: given let x at top level in a  
function body, existence of formal parameter x, and redeclaration of  
let x by top-level var x, are static errors.

2. Unifying var scope and let scope at top level in global code cannot  
work since var x creates a DontDelete property of the global object if  
no property x exists, else redeclares an existing property x having  
arbitrary attributes.

We could make let at top level in global code an error. Making such a  
let bind in an implicit block seems bad because inconsistent with 1,  
because implicit, and because it's more complicated to implement and  
specify than making global top-level let an error.

Any pragma of the "use lexical scope" kind:

http://wiki.ecmascript.org/doku.php?id=strawman:lexical_scope

would remove this restriction.

Comments?

/be

On Oct 13, 2008, at 6:41 PM, Brendan Eich wrote:

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