Constant Folding

The LSL compiler has some serious problems caused by the lack of constant folding. The most obvious one is that expressions like "PI / 2" have to be replaced by special constants, and if you need less common ones like "PI / 180" you have to initialise your globals at run time... which adds to the size of the script AND the heap. In addition, this means that negative numbers are tokenized as numbers to allow negative numbers to be used in global initialization, so that the expression a-1 is illegal, but a - 1 is legal.

Constant Folding is the general solution to this and other problems. It's one of the most elementary optimizations, and always a safe one for a compiler where the target language's arithmetic matches the source language's, like LSL. What constant folding does is defer code generation for expressions that only contain constants until the value is required to continue parsing, and to evaluate the constant expression at compile time.

LSL already does a certain amount of this in the generation of global vectors, casting integers to floats as necessary. There's no reason this can't be generalized, to allow constant expressions at the global level at least: this would always be safe because any failure to completely evaluate an expression is a syntax error. This would allow for the premature tokenization of negative numbers to be set aside... removing one of the common sources of confusion for new scripters, and save a huge amount of memory over a sim-full of scripts as people are able to make constant lists like llParticleSystem inputs into globals rather than assigning them at runtime.

Doing this throughout the code would further save CPU cycles wasted on calculating things like "PI / 180" over and over again, and memory wasted on extra variables used as constants.

Would the Mono transition include a new compiler? It could be that this will be done by Mono?
I would love to be able to put simple calculations like PI / 5 into my global declarations, instead of having to declare them empty then do it in state_entry(), which is still wasteful because if that state gets transitioned to it will recalculate them needlessly, unless I have a state specifically for initialising my variables! And anything that speeds things up is good.

I think it unlikely that they would make this kind of change at the same time as changing the code generator. At the very least it would be terribly unwise: I wouldn't want them to have to deal with debugging a new parser as well as a new code generator at the same time. It would be infinitely better for them to do everything they can to make NO changes to the parser immediately before or for some time after the Mono transition.

Rather, I want them to do this as soon as possible so that it can be working and debugged well before the Mono transition, and because it really is a very simple step that yields a huge payoff.