AutoHotkey Community

[interiot]

Has anyone given serious consideration to integrating Lua with AutoHotkey? That is, make it possible to run Lua-language scripts inside AutoHotkey, and allow them to call the same API, without changing anything about who's the primary one in control of the process/windows/etc. If a patch were created that enabled this via #ifdef's, would it have any chance to ever be integrated? (it sounds like a language-neutral layer might be welcomed, but that's probably more work, particularly if it means that AHK has to be modified to run compliantly inside another application)

It's obvious that AutoHotkey's GUI-enhancing code is adept, and is very popular because of that. But AutoHotkey-the-language has unnecessary complexity that makes it harder for new users to learn the language. AHK has two syntaxes for if-statements (with parens and without), two syntaxes for assignment (":=" and "="), two syntaxes for variable interpolation (with percent-sign and without), and two syntaxes for string literals (with quotes and without). Most languages have things to complain about, but these mean that assignment and conditionals -- two of the most frequently used features -- are harder to understand than they could be. Not only does this make it harder to write code (new coders guess-and-check almost more than with Perl), but reading existing code is more difficult too (because the same syntax can mean two different things, in a way that new users don't expect).

It is possible to update AutoHotkey to have a more consistent and non-overlapping syntax. That may require creating a toggleable backwards-compatibility mode (or at least strongly deprecating the older syntax and some function calls), implementing proper arrays, and maybe making references first-class. But that's a lot of work, and may take a lot of time because of the care and skill required to juggle backwards compatibility issues while avoiding future pitfalls.

Combining AutoHotkey-the-GUI-enhancer with Lua would also be a lot of work.* However, since the job is mostly just to glue together two already-working pieces, it's something that can't go really catastrophically wrong, and it's something that a random code-monkey may be able to accomplish.

*(back of the napkin: Wireshark takes ~6500 LOC to expose 146 function calls to Lua, and AHK's commands.htm lists 237 functions -- though those numbers wouldn't be directly comparable even after taking into account the AHK commands that are control-flow-oriented, or the AHK commands that are really bunches-of-commands-in-one)

[Tuncay]

Seriously, I don`t think that integrating Lua into AutoHotkey would help us much. That is a complete different language and has not much functionality that we could need. If ever someone needs Lua, he could use it via DLL-Call or just use the EXE executing the script.

There are much more other higher priorities, that we need more than Lua.

[majkinetor]

This was suggested number of times, and I agree that Lua in combination with AHK functionality is winning combination. AHK lang sucks IMO.

I was considering starting such project but currently I can not spend so much time. Maybe that change in the future.
_________________

[ryebread]

lua's structure is so good for embeding, and function is nearst for user

[Tuncay]

How would it look like, if really embedded? As a command or function? Is performance the only reason? Should AHK have really two independent languages inside?

[majkinetor]

[Tuncay]

Thx for clarification. If I have understand it correctly, no programming in Lua is needed, if embedded to AutoHotkey? My question about

[majkinetor]

No you didn't undrestand it correctly.

Just imagine you have this instead AHK langugage, and that you can use the same type of functionality.

In this case command syntax would be droped (the same is expected for AHK v2 anyway) and functions would be used instead. However, Lua functions are much more powerful then current AHK commands OR functions together. First thing is that you have named arguments, so Input command, translated to Lua would look like:

[Tuncay]

OH MY SHIT!!!

Wow and thx for the detailed explanation. Now I see how useful it would be. Thats really awesome, please integrate it, if possible. I intended just about easier calling functions or scripts...

[majkinetor]

Unfortunately, that will not happen as Chris doesn't see it that way. He also get attached to the language he is developing so its unreal to expect he will drop it (although it would clean the AHK Project and considerably reduce his work as he could concentrate on functionality and let the Lua team proffesionals handle the language and update it)

Also, it seems low probably that somebody else will do it as it requires total reorganisation of AHK code, and before that you must learn it well. IMO, its probably easier to rewrite AHK using current version as start up.

On some other forum places, almost all power members of the forum realised this is the best way to go, but as I said, its unreal to expect Chris will ever think in this direction mainly becuase he is the only developer and got very attached to his child.

Some quotes about the topic on developers forum

[Guest]

[Oberon]

I tend to agree with Chris' comments and the guest above me. AutoHotkey is original as it doesn't maintain a strict standard for flexibility and uses innovative hotkey syntax that's fairly easy to pick up. Lua enthusiasts can build their own version; Chris should continue to focus on developing for the current audience of non-programmers who want to get around Windows with the least hassle.

[majkinetor]

[Guest]

[majkinetor]

Ofcourse it can. But why.... because you like the C syntax ?
You can just go and use Ranorex. It is available for C.

In this case, its more then unaprpopriate considering the goals and history.