AutoHotkey Community

[thomasl]

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.

[Chris]

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.

[thomasl]

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.

[Chris]

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.

[thomasl]

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.

[Chris]

[thomasl]

[Chris]

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

[savage]

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>

[thomasl]

[arbe]

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:

[arbe]

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

[PhiLho]

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

[arbe]

[PhiLho]