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

save constants as variables #78

Open
lizelive opened this issue Aug 13, 2021 · 4 comments
Open

save constants as variables #78

lizelive opened this issue Aug 13, 2021 · 4 comments
Assignees
Labels
enhancement New feature or request

Comments

@lizelive
Copy link

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.

@lizelive lizelive added the enhancement New feature or request label Aug 13, 2021
@dbaumgarten
Copy link
Owner

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 Local Common Subexpression Elimination #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
Copy link
Author

lizelive commented Aug 14, 2021

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
Copy link
Owner

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".

This was referenced Aug 16, 2021
@dbaumgarten dbaumgarten self-assigned this Aug 24, 2021
@dbaumgarten
Copy link
Owner

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.

dbaumgarten added a commit that referenced this issue Dec 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants