Rework variables / const support

[adapap]

Currently, every variable is stored internally as a variable object, with a value and index property, if said variable was instantiated by the user. Internally, some variables, such as function declarations or for loop pointers are manually set. As they are internal values, they do not have an index. This leads to a lot of unnecessary confusion in development, as some cases require checking whether the variable is storing a Variable object (which further shouldn't be confused with a workshop variable). In order to standardize the way variables are stored and simplify things like closures and loops, reworking variables and their usage needs to be reworked.

Just storing the value will be tricky, as the interpreter needs to differentiate between a player variable and a global variable, a built-in or custom function, chase variables, etc. Ideally, looking up a variable in the scope table should get its literal value, while visiting it in the interpreter will return the appropriate Value In Array(...) syntax. It will be necessary to rework cases where variables are visited but expected to return non-string outputs.

[MatthewSH]

How, long term, would this benefit the language? It is in early stages, so some of these refactors could be justified. I'm a bit curious as well on will this affect the way we develop? Because if it changes it completely and you're follow SemVer then in theory this would require you to bump the major version to 2.0, and with that...we might as well look at starting a new branch and coming up with a variety of different quality of life changes and new features that could potentially break backwards compatibility.

[adapap]

• It would probably reduce a lot of complexity in the codebase, make variable-related bugs less frequent, and make implementing more high-level constructs easier at the expense of the time/effort to come up with a new variable system and integrate it
• Since this is a purely internal change, it would have absolutely no impact on the end-user as of right now - the same input will result in the same output; however, should a language server be implemented or tool that builds an AST from the code, there is a possibility of impact

[MatthewSH]

I think in regards to language servers, that wouldn't classify as too much of a breaking change because you're not breaking it for people using the language. Although, since it's in it's early stages...it's up to you.

I could definitely see how this would benefit it long term and I'm all for the change. It's pretty stable as is and doesn't seem to require to much bug fixing and changes other than the upcoming changes in PTR.