Discuss
  • function hoisting like var -- Was: Re: Surprising semantics

function hoisting like var -- Was: Re: Surprising semantics

# Ingvar von Schoultz (17 years ago)

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 you see above is function b() hoisting like var. This is the /exact/ functionality, apart from using two names. You can refuse the clearer syntax, but you can't refuse the above code and functionality.

b is bound to the global scope and assigned |undefined| before you enter the global scope.

Assigning |undefined| is correct for any function whose assignment depends on sequential code. The above is such a sequential dependency, even though it may not look that way.

What you're proposing is far too complicated.

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

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.

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/?

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.

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

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.

Or is the problem in the type declarations? Are datatypes of vars and functions fundamentally different?

Or is it because functions have parameters? You're not saying anything about parameters, so if that's the problem you're being very vague indeed.

See my previous email as to why.

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.

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.

Ingvar