Re: Lua code generation and optimisation

[Coda Highland <chighland@...>]

On Thu, Oct 4, 2012 at 3:00 PM, Thijs Schreijer <thijs@thijsschreijer.nl> wrote:
>> > 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.

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

/s/ Adam