AutoHotkey Community

I think ahk could benefit from the inclusion of a full fledged preprocessor. Really, you could fake it by just running it through a seperate preprocessor and then spitting out a temp file to be run by ahk, but full integration would be better.

I did a google search for preprocessor and came up with the Generic Preprocessor, which I guess will work for any language. At first look it looks promising if a bit overkill. If that doesn't work I'm sure there are plenty of others out there that could easily be incorperated into ahk.

I'll try and look into it a bit myself, but unfortunately my c++ capabilities are a bit limited, so it may be out of my league.

Can you give an example of what it would be used for in a script?

First off I should probably explain that a preprocessor is a program that you run your code through that will basically just do an advanced search and replace to your code using terms you provide using special syntax in your code. A common task that is preformed by preprocessor is defining constants, so at the top of your program you say replace all instances of the word PROGRAM_VERSION with 1.13 and then down where you output the program version just write PROGRAM_VERSION instead, then when you run your source through the preprocessor, it will generate a copy of your source except that all instances of PROGRAM_VERSION have been replaced with 1.13, then you run the generated source through ahk.

Obviously in ahk you can just use a variable to do that sort of thing but preprocessors can also do more advanced things.

The main things I can see uses for is macros, similar to the ones in c. While macros aren't the most elegant solution, and eventually should be replaced with features in the actual language (which is probably why they are more and more being depreciated in c++), they are extremely powerful tools, especially in a language as immature as ahk.

Here is a simple example:
I often take advantage of the Transform deref function to get the values of variables whos name I generate on the fly, like for arrays or something.

Transform is lengthy and is can clutter up code, using the c preprocessor (for example) you could write:

This example doesn't give us huge amounts of benefit, but more complex macros can save a lot of time by generating complicated reusable code automatically.

I guess I should be clear that preprocessors are designed to help write code, not write programs. By that I mean it's there to get around annoying syntax or making complicated tasks simpler, but can't really do much in terms of adding power to the language, since in the end the script passed off to ahk will still have to work within the limits of the ahk language.

Thanks for the great examples.

If it weren't for the goal of keeping AutoHotkey as small as possible -- expecially AutoHotkey.exe so that it launches quickly and so that compiled scripts are kept small -- I would consider immediately adding a pre-made preprocessor such as the one you mentioned. Another disadvantage is that AutoHotkey is targetted toward non-programmers (which is not to say that programmers wouldn't want to use it, since myself and many others do so heavily). As a result, most of its user base would probably never use the preprocessor features.

Still, GPP might not be too bad, perhaps adding less than 30K to the size of the EXE (at a guess), so I will consider it (or perhaps sections of it) for the future. I will make a to-do entry to read this topic again when the time comes. Thanks for suggesting it.

One of the things I'm hoping to get done before any kind of pre-processor is support for subroutine parameters and return values, as well as some basic handling of complex expressions. I think this is a higher priority than a pre-processor. For example:

x := MySub(%var1%, %var2%) / 100

MySub(param1, param2):
...
return 33 ; Value to return to caller.

Very much appreciated to get that description. Thx, Simpleton



Yes, I confirm. As I'm one of them

That seems reasonable. On a side note one nice thing about the preprocessor is that when you compile the script it could compile the preprocessed code, so that it wouldn't have to re-process it each time it ran.

That's a good point. By doing the substitution prior to compiling, the preprocessor module could be omitted from each compiled script, which would reduce the size of each Script.EXE file.