return when desugaring to closures

Waldemar Horwat waldemar at google.com
Mon Oct 13 17:29:54 PDT 2008


Brendan Eich wrote:
> On Oct 13, 2008, at 3:51 PM, Waldemar Horwat wrote:
> 
>> Brendan Eich wrote:
>>> After some experiments, we decided for ES4 to make let and var the
>>> same at top level in a function or global code.
>>>
>>> This helped avoid implementation pain: very long scripts on the web,
>>> consisting of many statements in a row, motivate statement-wise
>>> parsing and cumulative code generation, which is straightforward in
>>> the absence of goto. Yet scope changes (e.g. due to a tardy rogue let
>>> x; after thousands of statements the first of which uses x) require a
>>> separate pass to generate the necessary block set-up code before the
>>> first use of x.
>>>
>>> Unifying let and var at top level also reduces the cognitive load
>>> (number of scopes in mind) and eliminates useless name shadowing
>>> opportunities.
>>>
>>> But such let/var unification at top level in a function body does
>>> leave bad old arguments[0] aliasing x in the above example, allowing
>>> mutation of otherwise lexical let x; (change var to let and fill in
>>> the ... with arguments[0] = 42; return x). The answer that we chose
>>> for ES4, and the one that's already agreeable in committee for
>>> Harmony, was "deprecate arguments by providing optional and rest
>>> parameters".
>>
>> You can't do that.
> 
> Which "that" do you mean?

Turn let into var at the top level of a function body.

>> function f() {
>>  x = 15;
>>  ...
>>  let t = some_runtime_expression;
>>  ...
>>  let x:t = ...
>> }
>>
>> What is the type of x at the beginning of the function?
> 
> The example had better fail to compile.

Because presumably the "let x:t" became "var x:t" and var can't have types?  You can't be serious that let would be broken unless enclosed by an independent block!

    Waldemar


More information about the Es-discuss mailing list