Functions ignore declaration order

[Denneisk]

Allow user-defined functions to be called from anywhere in the script even if not originally defined.

i.e.,

func()

function func() {
    print("Hello, World!")
}

should compile.

[thevurv]

If we do this then we absolutely lock ourselves into functions not having upvalues. Just want to make sure you're aware of this and that everyone is okay with that.

(This JS/TS code errors at runtime, but I wouldn't want it to do that but instead error at compile time.)

test();

let y = 2;

function test() {
    console.log(y);
}

[Denneisk]

That kind of sucks but might just have to live with it. TS functions can retain upvalues but I'm not sure how reasonable that is with compile-time functions (especially with a hack like this). Lambdas should hopefully be just-as-good if users need that dynamism.

[Divran]

why separate the concept of functions and lambdas? Just treat them as the exact same thing just like lua does. Makes the language a lot easier to understand if there isn't two very different behaviors depending on which way you happen to arrange the words, ie function name() {} versus name = function() {}

[Denneisk]

I'm obviously not the right person to ask but I think it's just complexity. There's nothing stopping future E2 from being able to properly parse the following code

let func

{
    let y = "Hello, World!"
    function func2() {
        print(y)
    }
    func = func2
}

func()

I think it's just not a good idea to pursue it without having the proper framework beforehand (being able to cast compile-time functions to a lambda (or vice versa), plus all the other convenience that normal functions give like compile-time type inference).

[thevurv]

why separate the concept of functions and lambdas? Just treat them as the exact same thing just like lua does. Makes the language a lot easier to understand if there isn't two very different behaviors depending on which way you happen to arrange the words, ie function name() {} versus name = function() {}

Because that adds a good amount of overhead. I'm treating functions / lambdas as lower level languages do. Maybe that isn't as fair since the syntax is like typescript, where they are practically the same.

Functions don't have upvalues since they're supposed to be created once at compile time now. Same as events. This was originally to address the problem of people having to nest their functions in if(first()) with the trigger system. Maybe sooner it'll become less common to have this issue and this will be less of a reason to have them be static.

Anyway, for the big reason -- lambdas are not strictly typed at compile time, so they can't/won't be interchangeable with functions. They could be casted to lambdas as denneisk says, but I want to be very careful with that as it could get very confusing. At least right now there's a clear separation between the two. If I were to implement it I'd at the very least want it to be explicit, ie

const Lambda = myfn as function