function hoisting like var

[waldemar at google.com]

Ingvar von Schoultz wrote:
> waldemar at google.com wrote:
>> I'm trying to keep the language relatively simple.
>
> You can't get away from supporting this:
>
>     {
>         function a(){}
>         var b = a;
>     }

What do you mean?  This is a syntax error in both ES3 and ES3.1.

> On the contrary, the functionality already exists, as shown
> above.

It does not already exist in ES3 or ES3.1.

>> Keep in mind that function assignments hoist to the beginning of the
>> scope
>> in which the function is defined, so your proposal won't work.
>
> When the programmer explicitly says that the assignment depends
> on sequential code, then do what the programmer says. Anything
> else is an error. Do it by assigning |undefined| before scope
> entry. This is the only correct thing to do.

I don't understand.

>> You're
>> trying to do a complex split-scope approach where each function
>> definition
>> has *two* scopes, one in which it is declared and one in which it is
>> defined, but even that won't work with const, typed functions and
>> variables, etc.
>
> Are you saying that the function /body/ gets into trouble,
> or the function /name/?

Both.

> The function /body/ stays where it is. The hoisting doesn't
> affect it in any way. Moving the body would change its context
> and meaning catastrophically. Don't touch it.

That doesn't answer the question.  The problem is that the body can
capture variables that haven't been declared yet.

> The /name/ becomes a var. Treat it like any other var. Hoist
> it and assign |undefined|, exactly like you do with other vars.

That's incompatible with how functions are defined in ES3.

> Are you saying that because this var is related to a function
> it can't be treated like other vars? Is this var fundamentally
> different from other vars? At least above it isn't.

Huh?  Do you understand how ES3 works?

> That email is about some wildly unworkable dynamic scoping.
> It has nothing to do with anything I ever said. You jumped
> to that conclusion.
>
> Please stop insisting that I'm proposing that nonsense. I'm
> not. I never did.

I haven't seen a sensible and compatible proposal yet.

>> You'd then have to
>> introduce extra rules about some definitions only being possible within
>> {{}} blocks, which would then affect the behavior of existing definitions
>> like var if one of the other definitions within the same block was a
>> const
>> or function, which would snowball into a complex mess.
>
> Unrelated, I believe.

So you're saying that your {{}} proposal has nothing to do with this?

    Waldemar