AutoHotkey Community

Would the following be difficult to implement, Chris?

Whenever AHK is about to read a source file from disk (say xyz.ahk), it should optionally call another, user-defined program, give this program the filename, wait until the other program is finished, load instead a file called xyz.ahk.preprocessed (or similar) and delete this afterwards. A hook, in other words.

This would also have to be done with included files but I suspect it could be done in such a way that it is fully invisible from the outside.

Background: with such preprocessing in place we would write small scripts (converted to EXEs) or programs or filters that could do all sorts of good things with AHK source code (among other things I could get rid of the blasted = vs := issue). But there is much more, of course.

My first impression (without having considered it deeply) is that I'd be reluctant to build in something like this because of the expectation that fewer than 1% of users would use it.

Couldn't you have a master script parse and rewrite a second script and then launch it?

On a related note, there is a tentative plan to have some preprocessing features in AutoHotkey. It might take the form of simple substitutions done at load-time. For example:

#define MaxRetries 30
MsgBox %MaxRetries%

Now that I look at this, I don't see much benefit to it other than avoiding the creation of variables whose values will be constant. But I know there are other uses of preprocessing that might justify adding features like this.

Your example (#define...) is not what I had in mind. I agree with you that there is not much of a point in doing this sort of thing.

What I thought of is a much more comprehensive scheme where one could literally define a new language, preprocess it (ie. translate it to AHK syntax) and feed the whole thing into the AHK executable.

I had thought about doing a two-step process myself. The problem here are includes: I have big scripts which include quite a few files. This makes a simple approach difficult and error-prone.

I'd appreciate if you could have a look into that.

Perhaps you could provide more details of the plan, especially the benefits it could provide. In addition to helping me understand it, this might inspire others to comment, which can help build enthusiam.

Let me take an example we had the other day. Somebody talked about AHK not having a case/switch statement. With a preprocessor (which could actually be just a few lines of Perl) you could easily implement case/switch in terms of if.

Let's take free form stuff. AHK's parser is very strict (to put it midly). With a preprocessor you could have a free form script. [[Free form means that stuff must not necessarily start at some prescribed position, like { for functions.) This is valid AHK:

Blabla()
{
Run, blabla
}

This is not and it's pretty strange that it isn't:

Blabla() {
Run, blabla
}
]]

With a preprocessor one could get rid of the dreaded := vs = discussion. And so on. And of course preprocessing would be invisible to people who don't need or want it.

Good example.

That's a good point. The reason it isn't valid is due to a carry over from the fact that "{" can't exist on the same line as an old style IF-statement (since it would be ambiguous). I've made a note to look into relaxing these restrictions in places where it would do no harm.

It probably wouldn't be hard to add this now as something like:

#Expr If =

The symbol "=" makes "=" become ":=". The word "If" (if present) would all IF-statements become expressions. There is probably a better name and syntax for the above, so it's just a crude example.

As for your hook idea, it would not be hard to do. It would just be a question of devising the proper interface/syntax in such a way that it does not degrade performance or the future extensibility of the program. A command line switch is probably the answer, though perhaps it could also be done as a #directive inside the script file.

Of course, it would be also preferable that it be small in code size, which seems likely. This is because I expect that fewer than 1 out of 1000 users would use this feature, at least until such time as someone released a new AHK syntax package that people could download so that they can write with the custom syntax.

Finally, although I could add this to the to-do list, you'll probably get a much faster response to write the code yourself, perhaps with an intermediate program to which .ahk files are associated. That intermediate program could translate the script and then launch it with AutoHotkey.exe.

I would go for a simple command line interface. This is cleaner than a directive. Even better might be a separate extension: .ahkpre or so.


If it were so simple I would have done it long ago. As I said before includes are the big problem here: I can do nothing about AHK including a file. I would have to translate that asynchronously -- and that begins to sound like something that needs a makefile. I am not sure that this is the best way.

You're right, I keep forgetting about those #Include files. However, #Include isn't a very complex section of code. It's basically just a recursive call to the load-script function. So I think you could implement #Include handling in a go-between program by using recursion in the same way.

The reason I'm reluctant to work on this right away is the expectation that very few users would ever use it. Consequently, I keep urging myself to stay on track with the priorties in the to-do list (there have been times when I've gone off on low-priority tangents for several days at a time).

What were you planning on doing the preprocessing with? Perl scripts or a dedicated preprocessor like m4 (icky syntax) or gpp (nice)? I've been planning on replacing my main script with an intermediary that would auto process and run the other one, but I haven't come up with a really compelling reason to work on it.

_________________
<enormous animated gif>

I use Perl for the really complicated stuff and something called HTMLPP for the simpler, mostly file-based things (that's an HTML preprocessor but it does a good job for other things as well).

M4 needs another preprocessor to be usable, so I only used it once or twice.

Hi Chris,

I do believe that preprocessing might be interesting for many users, especially those who compile their scripts for the public.

I would use a preprocessor to have an integrated main script for personal and publishing intention:


Additionally to this syntax, #ifnotdef is useful as well.

All third party tool solutions are not compatible with #include files. Even if they handle them internally, any changing of .ahk files would result in AHK debug messages showing wrong line numbers.

It would be great if you could give us some hint on when this issue might be implemented.

Another popular use case will be to define the DEBUG preprocesser switch. That way, extensive logging can be enabled/disabled with changing just one line.

The preprocessor is preferable to regular if statements due to not blowing up the (compiled) script, both in size and runtime speed (despite the last one probably being marginal).

For regular scripts, that are interpreted, such preprocessor is useless, as you can do everything with the language itself.
Lua (another scripting language) integrated some preprocessor commands in its early days, they dropped them a long time ago.

Now, with the last message, I recon this can be useful for compiled scripts. But actually, you can do the same thing with existing syntax: just replace #xxx with ;#xxx, process the source with some tool, be it written in AHK, awk, Perl, whatever, and then happily compile the resulting file. It is flexible (choose your prefered tool) and doesn't add anything to the language itself.

_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

That's correct. You can do this task with tools. But this is a philosophical question: Why need C++ when you can do everything in assembler? Why need AHK function calls when you can do the same with gosub?

Your "quick and dirty" approach of commenting out unwanted sections might work, but is not elegant at all. A preprocessor would not blow up the language itself too much and would provide a much cleaner solution.

Not "commenting out unwanted sections", but creating custom commands, starting by ; so AutoHotkey will happily ignore them, but still easy to find by an external tool.

Indeed, you can cram in lot of features in the language, at more or less cost.
Preprocessing is probably not very costly too.
But as I pointed out, it would be used mostly to create different compiled scripts depending on choices, so the scope of utility is rather limited (I never use ahk2exe).
Unless you give some creative examples showing off how processing the sources before running them could be useful and couldn't be done currently.

I am not really hostile to the idea of preprocessing done internally. I just want to be convinced.

_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")