dbaumgarten / yodk

Development Kit for Starbase's ingame programming language YOLOL
MIT License
56 stars 16 forks source link

save constants as variables #78

Open lizelive opened 3 years ago

lizelive commented 3 years ago

Is your feature request related to a problem? Please describe. very common thing that we need to do by hand, would be nice if it could be done automatically. ideal would be a flag to set how many useages to do this for.

Describe the solution you'd like either:

  1. find constants, define them at top of script
  2. add const deceleration that gets saved as variable for example :x=math_pi+sqrt(math_pi*:x) should compile to :x=3.142+sqrt(3.142*:x)

Describe alternatives you've considered doing this by hand is tedious.

Additional context Add any other context or screenshots about the feature request here.

dbaumgarten commented 3 years ago

This problem effectively consists of two parts:

  1. Local Common Subexpression Elimination. Use a temporary variable to store long expressions (constants, global vars, formulas) that are used multiple times in one line. For this there is issue #42. I am already working on that, but getting it 100% correct is a little complex. However, once it works, applying it would always be correct and would never result in worse code.

  2. Globalization of constants Move some/all constants to the beginning of the scripts and store them in local variables. That would be helpful pretty often, but it is hard to determine when to globalize a constant and when not. In the worst case, unnecessary globalizing of constants could make a script actually worse. I would really like to implement this, but I am not sure how to make it a opt-in feature, or if I should simply make it always-on and accept that it might sometimes do stupid things.

lizelive commented 3 years ago

I was thinking only about part 2. I think always on is good enough for now as line length is a lot more problematic then line count. basically if its not an int 0-9 outline it. but yodkconfig.json config file would make life better.

dbaumgarten commented 3 years ago

I will probably add part 1 and 2 soon-ish. But as they require quite some testing it won't be in the next released version (which will just contain Bugfixes and minor features).

I don't really want to add a separate configuration-file. I think that would just create confusion. If there is a setting to enable/disable specific language-features it would be some kind of keyword in the language itself. Something like javascript's "pragma" or bash's "set".

dbaumgarten commented 3 years ago

Just a small update on this: I have started working on it and even got it to a somewhat working state. But it still requires a bit more work to make sure it doesn't break anything. All the bug-reports and smaller feature-requests have kept my busy, so I didn't find the time to finish this, but it has not been forgotten.