Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make functions a compile time construct on @strict #2789

Merged
merged 5 commits into from
Nov 12, 2023

Conversation

Vurv78
Copy link
Contributor

@Vurv78 Vurv78 commented Oct 13, 2023

No overriding

Overriding functions at runtime is no longer a thing on @strict. It's rare, odd dynamic behavior that shouldn't really be a thing. Function objects will fulfill their purpose in the future.

@strict

function test() {}

function test() {} # ERROR!

It gives a warning without @strict for backwards compatibility.

Compile time

Like events, functions on @strict will now be compile time constructs, so it doesn't matter if they're inside an event tick() {} loop or something. The function will just be created once when the chip is compiled.

Basically: they will be cheaper to call and create. I raised the cost of calling functions on non-@strict, but the base cost is still 10 ops (will likely be lowered in the future).

Breaking Change to String Calls

Since they will be compile time constructs, string calls to userfunctions won't work on @strict (will get a "no such function" error). This could be reverted while keeping the perf boost from calling, but the cost of creating the function will still exist.

I think it is a worthwhile break since stringcalls should hopefully be made obsolete soon with function objects.

@Denneisk
Copy link
Member

Denneisk commented Oct 29, 2023

<--- Didn't read the first section of this PR

I think as a useful median between first class functions, functions names/signatures should be able to be overwritten. That shouldn't be a problem in a future where you could do Function = function(Args)[Type]{...}, Function = function(SameArgTypes)[SameType]{...}.

# library.txt
function void table:myLibraryFunc() {
    error("This is a stub! Define it in your code!")
}

.........
# file.txt
#include library.txt

function void table:myLibraryFunc() {
    print(This)
}

e.g., I wanted to create a library in E2 that works best with function references but to do so would require disabling @strict with this change, which isn't ideal, so my idea was to instead have it call one function that the user implements. I guess I could also simply not define it but it'll produces errors everywhere in the library.

@Vurv78
Copy link
Contributor Author

Vurv78 commented Oct 29, 2023

<--- Didn't read the first section of this PR

I think as a useful median between first class functions, functions names/signatures should be able to be overwritten. That shouldn't be a problem in a future where you could do Function = function(Args)[Type]{...}, Function = function(SameArgTypes)[SameType]{...}.

# library.txt
function void table:myLibraryFunc() {
    error("This is a stub! Define it in your code!")
}

.........
# file.txt
#include library.txt

function void table:myLibraryFunc() {
    print(This)
}

e.g., I wanted to create a library in E2 that works best with function references but to do so would require disabling @strict with this change, which isn't ideal, so my idea was to instead have it call one function that the user implements. I guess I could also simply not define it but it'll produces errors everywhere in the library.

Either the library should define table:myLibraryFunc() or the function should be taken as a callback to another function.

@Denneisk
Copy link
Member

Denneisk commented Oct 29, 2023

Either the library should define table:myLibraryFunc() or the function should be taken as a callback to another function.

Actually, maybe a better solution, if you could add UDFs to #ifdef then this could be mitigated without adding overriding.

@Vurv78
Copy link
Contributor Author

Vurv78 commented Oct 30, 2023

Either the library should define table:myLibraryFunc() or the function should be taken as a callback to another function.

Actually, maybe a better solution, if you could add UDFs to #ifdef then this could be mitigated without adding overriding.

Yeah, which would require removing overriding / "runtime" functions. I'm ofc open to that even if I think #ifdef should probably be scrapped in favor of a more general #if in the future

@Vurv78
Copy link
Contributor Author

Vurv78 commented Nov 9, 2023

Should be merged after #2829 for the people currently using stringcalls and @strict for whatever reason

@Vurv78 Vurv78 merged commit a4e6c4f into wiremod:master Nov 12, 2023
@Vurv78 Vurv78 deleted the fn-override branch November 12, 2023 23:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants