LuaPreprocess - straightforward preprocessor with simple syntax

[ReFreezed]

I think the URLs aren't correct

Whoops. Fixed it. That's what I get for running a local test server. I even thought about it but apparently I'm blind. lol

[ReFreezed]

Update 1.16

Changes since 1.15:

Library:

• Added preprocessor symbols (in the form of `$name`).
• Added functions: startInterceptingOutput(), stopInterceptingOutput().
• Macros can use `outputLua()` and co. instead of returning code.
• Detecting errors such as `!(x,y)`.

Preprocessor symbols

While programming, I noticed how I wrote !!(foo) a bunch of times in some places and it just looked a bit cluttered, kinda like this:

Code: Select all

!!(guiElement).!!(event) = eventHandlers.!!(event)[!!(guiElement).name]

Using symbols the same code now looks like this:

Code: Select all

$guiElement.$event = eventHandlers.$event[$guiElement.name]

It's a bit more readable now, right? It actually looks like Lua code again. I think it's a small quality of life improvement.

[yetneverdone]

About this new token $, it seems that it expects the value from the handler to be string, maybe allow other values?

Code: Select all

--handler
_BAR = 5 --wont work
_FOO = "5"

--main.lua
local foo = $_BAR --errors
local bar = $_FOO --okay

this is the same behavior with function

[ReFreezed]

It expects the value to be a string containing Lua code - the same as !!(). It doesn't make sense to allow other values as no other value can represent Lua code (except maybe functions, but there isn't really a good way to turn functions back into code).

Code: Select all

_BAR = toLua(5) -- This happens to produce the string "5".

[grump]

Hey, can you make this accept input from stdin and output to stdout? Or at least support single file processing?

[ReFreezed]

Sure, I'll add support for stdin and stdout as input/output.

You can process a single file from the command line using preprocess-cl.lua. Unless you mean something else? Do you mean reading and writing to the same file?

[grump]

Nah. I gave it a try it a few months back and gave up immediately when it didn't allow me to give it a single file on the command line. I can't remember the details, sorry. I may have done it wrong. I'm a huge sucker for Unix pipes.

I just want a debug switch that works as simple as possible and properly handles zero-cost assertions, like a C preprocessor.

What would be really cool: if it registered itself as a package loader so you don't even have to have a separate preprocess step. Also moonscript support, but that seems a little bit out there.

[ReFreezed]

I'm mostly familiar with Windows so there's a possibility something doesn't work on other systems (though I don't know what that would be). My own usage of LuaPreprocess is either by using the command line tool to process a single file (very simple, no "pipeline", usually for new projects I haven't made a proper build system for yet) or by making a build script in Lua that requires the library (and LuaFileSystem and whatnot) and handles all steps that would otherwise require some sort of command line piping. I like using the command line for as little as possible.

Anyway, since specifically a C-like assert seem to be in high demand, maybe there should be some functionality specifically for that in the library. I could provide an assert function/macro that normally outputs code, and add a parameter that disables it. Are there other things that should work the same way (i.e. gets enabled/disabled by a debug/release flag of sorts)?

About the package loader, I feel that kind of defeats the purpose of a preprocessor a bit (if zero-cost things are of value). I'll probably wait with implementing such a thing, if I ever do.

For Moonscript someone would have to make a MoonscriptPreprocess library.

[grump]

About the package loader, I feel that kind of defeats the purpose of a preprocessor a bit (if zero-cost things are of value). I'll probably wait with implementing such a thing, if I ever do.

Zero-cost at call time is what's important, not so much parse time.

Adding just one require to your code and having a fully-fledged preprocessor from then on, with no further build process requirement, seems like a good thing, no? It's what I appreciate most about moonscript - I don't even need to compile anything. It just works out of the box. I only have to offline-compile when it's time to ship my project, and I don't even have to think about it before then.

The C preprocessor would suck if it required an entirely separate build process.

[ReFreezed]

Eh, I don't fully agree with what you're saying. One reason to use a preprocessor, or rather, have a build step is to offload expensive computations that only need to happen once ever from runtime (even if it's at startup time) to build time (i.e. no one but the developers need to wait for the computations ever). Start-up/load time matters too.

I can kind of see how having a package loader for this while developing could be useful, but I don't see how you'd transition to not using a preprocessor at runtime in a release build. Should require() write the processed files somewhere while you're in dev mode so that the release build can load those as fallback when LuaPreprocess isn't available? That would mean you'd need to hit every require() call at runtime for all files to get updated, and there'd have to be a system in LuaPreprocess for it to know where to save files. That doesn't seem good. Maybe that stuff fits better in a separate library (like the command line program). I dunno.

Having more power available at minimal effort on the user's side doesn't have to be a good thing if the negative implications are too big. After all, the Lua language used to have a preprocessing step before they decided the negatives outweighed the positives and removed the feature. How many different features that has little to do with preprocessing should LuaPreprocess have before things have become a mess? It's just a preprocessor - not a build system, nor a different language like Moonscript. I'd like to limit the extent of the library to the things that are both relevant and useful, and I'm not convinced involving any runtime stuff in a preprocessor is such a good idea. (Again, it might fit in a separate library.)

And my opinion is that the C preprocessor does suck. It's possibly one of the worst examples of how to make a preprocessor. It uses a separate inferior language to solve problems that should've been solved by features of the language itself (not to mention the slew of other problems C has). And how many C projects doesn't use something like CMake when building programs (i.e. a separate system involved when building)? A difference between this preprocessor and the C preprocessor is that the former outputs executable code directly while the latter need at least another step before the program can run - the actual compilation (which involves creating object files, using linkers, and other garbage). Excuse the negativity, but C really isn't in a good light in my eyes.