RE: Lua code generation and optimisation

["Thijs Schreijer" <thijs@...>]

> >> > I would better use standard Lua syntax with a normal "if", but
> >> instead
> >> > use a specially marked condition. Something like :
> >> > ----
> >> > function COMPILE_TIME(cond) return cond end
> >> >
> >> > if COMPILE_TIME(condition) then
> >> >   print("something")
> >> > else
> >> >   print("something else")
> >> > end
> >> > -----
> >> >
> >> > The advantage is that it the script will run normally unprocessed,
> >> > no matter what "condition" is.
> >> > Now, since Lua language is not very difficult to parse, it should
> >> then
> >> > not be a big problem to write a filter that looks for "if (not)?
> >> > COMPILE_TIME(.*) then .* end" pattern, evaluate the constant
> >> > condition, and outputs a scripts without those runtime tests.
> >> >
> >>
> >> Seconded! Such a thing would be very nice for debugging, too, since
> >> it means you don't have to "recompile" Lua code when testing
> changes.
> >
> > Probably me, but I'm not getting this. In what case would you have to
> > 'recompile' and when don't you have to 'recompile'?
> >
> >
> >
> 
> Well, theoretically speaking, you could preprocess the expressions, or
> you could compute them at run-time. They should have the same results
> as long as the constants don't change (and with a little bit of
> setfenv/_ENV magic you can ensure that). So this gains you the
> advantage of being able to run the un-preprocessed version, for example
> in a debugger where you can examine the original context instead of the
> postprocessed context.

The last example I gave also runs without preprocessing. The only advantage
the above has is that is can 'dynamically' switch because the expression is
evaluated every time. But I doubt whether you should even want that, as it
might introduce very subtle bugs that differ from debug to production code.
I for one would rather stay away from that.

> 
> You'd want to run the preprocessor when speed and/or size counts, and
> you'd want to not run it when mapping line numbers to the source file
> is important or if you don't have the preprocessor installed (optional
> build-time dependency, basically).

Imho the preprocessor should never 'remove' lines, either comment out (as
with --# I mentioned) or 'empty' them (if size matters) so it will not
change any line number information. Just 1 byte for each line that could be
gained when really deleting the entire line, whilst retaining proper line
numbering in errors/troubleshooting (even in production code).
If that last byte counts, then distribute byte code.

Preprocessor should then handle 2 'run modes';
1 - adaptive; commenting one part, uncommenting another (or any
combination). Always allows to reverse to the previous situation by running
the preprocessor again with different symbols set.
2 - destructive; emptying the excluded lines, cannot be undone as the code
is lost. Useful for distributing.

The second one differs from;  number 1 + 'minimizer tool', in that it
retains linenumber information


Thijs