-
-
Notifications
You must be signed in to change notification settings - Fork 28
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
Constant term pre-evaluation #139
Conversation
This reverts commit ed2e4b7.
@juliusfrost Do you think you can get some numbers on how this affects compile time? And maybe places (i.e. in the pioneer program) that benefit from this? Most likely stuff like hardcoded keys that can now be written as "bytes.fromhex" |
I just checked the examples and they have converged to a state where there is almost nothing that could be constant folded (except for some PlutusData constants). Might be a results of this feature missing so far though. |
Maybe stuff in the interval api? Would methods like |
As of the current state, thats not the case. I guess constant folding is a bit misleading as we are just preevaluating static expressions. What would be interesting is to propagate/fold properly, but this requires more sophisticated analysis 😅 |
Since this only adds 0.1s to the testbench, I will merge this feature. Notably, proper constant folding is still a desired feature and may follow later (potentially even based on this implementation). Hopefully users won't get too confused about the fact that certain statements work as long as they are constant (i.e. |
This proposes a single optimization, that improves two things at once:
bytes.fromhex("0011")
andlist(range(0,10,3))
)2**24
is not computed on-chain but at compile time)One final thing that needs to be addressed here is that we need to keep track of user-defined scopes (potentially re-assigned variables)