Integrating Lua into AutoHotkey
Posted 16 February 2008 - 01:54 AM
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)
Posted 17 February 2008 - 03:25 PM
There are much more other higher priorities, that we need more than Lua.
Posted 18 February 2008 - 08:21 AM
I was considering starting such project but currently I can not spend so much time. Maybe that change in the future.
Posted 19 February 2008 - 02:26 AM
Posted 19 February 2008 - 09:29 PM
Posted 20 February 2008 - 12:21 PM
It would look awesome.
How would it look like, if really embedded?
As a command or function?
No. The power and simplicity of Lua language is well known (thats why its used in games, programmed by kids and non programmers, pretty much similar to goal of AHK author). You have all advanced concepts of mainstreem languages like objects, lists, arrays, function pointers, metaprogramming etc... in language of 100KB size.
Is performance the only reason?
No, AHK functionality can be made in such way its usable with any languages (for isntance dll). After that, author of AHK could continue developing its own language if he wants, but you will not be limited with it any more, like you are today.
Should AHK have really two independent languages inside?
Posted 20 February 2008 - 08:36 PM
was, interface of Lua integrated as a command style or as a function style?
As a command or function?
My question at this point is now: Would the AutoHotkey user ever have to program in Lua? Or is that implementation any kind of for the Author of AutoHotkey itself?
Posted 21 February 2008 - 08:44 AM
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:
Input, out,title, , , , , , , , ,, ,, , , , ,, default text ;AHK version out = Input(title, "", "", "", ...... , "default text") ; lua version out = Input(title, Default="default text") ; lua version, using named args
Also, in Lua functions can return multiple values, so instead
MinMax(val, min, max) ;ahk ver, min & max are byRef min,max = MinMax(val) ;lua version, MinMax returns 2 values
Among other things Lua code is MUCH shorter and elegant and you can do things like
x = Input x(title, Default="def text") x= MinMax y,z = x(val)
So, embeding Lua doesn't mean that you take this version of AHK and add Lua (although possible) but that you separate AHK language from AHK functionality, then let the people use their own language, and let someboedy else compile AHK functionality part with Lua language instead AHK language. Any combination is possible.
One obvious tremendous benefit of using Lua is that just by embeding it, you will have access to hundreed of libraries, using Lua's include statement. For instance, you could include entire winwdows API more naturaly and never use DllCall, or you can choose to use wxWidgets as GUI framework instead AHK GUI. All that comes for free when you embedd Lua. Callbacks, better Dll calls, structures, and all things we have problem with in AHK are already there in Lua via some of the includes or internaly for long time...
Posted 21 February 2008 - 09:28 PM
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... :!:
Posted 22 February 2008 - 11:14 AM
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
If we are speaking about syntax changes, we could eliminate the command syntax, and use only function calls
Although I see the merit of attaching an AutoHotkey DLL to a more professional programming language like Lua, I don't think most users of AutoHotkey would want to learn a new language (even one as easy as Lua). In fact, I don't think most users of AutoHotkey see themselves programmers, which is why I've put most of my time into AutoHotkey's "missions/specialty areas" instead of general programming features. I never wanted AutoHotkey to be seen as "yet another programming language".
If Lua were to become the new language for AutoHotkey v2, much of this simplicity would be lost.
Since I know very little about DLL creation, it would probably fall to someone else to add this feature if they want it.
Creation of an AutoHotkey DLL has been asked often, the answer is that Chris doesn't want to spend time and energy on this, which is fair. And that the source is here for taking: extending AHK might be hard, because the parser and language features aren't simple beasts, but extracting a functionality like WinWaitActive shouldn't be too hard, and that's what a DLL should be: no language, just smart wrappers around WinAPI.
I'd like to see Python or JS more, but without volunteers, those may never happen.
Lua is Python influenced language and it is 10x faster and smaler then Python. JS is also more costly to embed then Lua.
Embeding Lua can be learned in days. Mastering that topic is probably as time expensive as anything else but that shouldn't be limitation.
The point is not to choose the best language to embed AHK into. Many of us have to use one language or another, which is adopted by our employers. A large corporation will not drop hundreds of Python projects in favor of LUA, so we would need to support several languages.
I believe having a DLL with (most of) the functionalities of AutoHotkey would be great, and a big step toward integration to other languages.
This is how it would look like, if we imagine. This is fictive sample about using wxLua GUI framework (check out screenshot of wxLua controls here)
-- include wxWidget library require 'wxLua' frame = wx.wxFrame(wx.wxNull, wx.wxID_ANY, "wxLua Minimal Demo", wx.wxDefaultPosition, wx.wxSize(450, 450), wx.wxDEFAULT_FRAME_STYLE) -- create a simple file menu local fileMenu = wx.wxMenu() fileMenu:Append(wx.wxID_EXIT, "E&xit", "Quit the program") -- now we imagine pid, class, title = WinWait("Notepad") if class = Notepad_class then WinActivate( class ) frame:Show(true) else MsgBox (text="Notepad can not be found, just some window calling itself that way...", options=16)
Posted 22 February 2008 - 01:19 PM
...and all things we have problem with in AHK are already there in Lua via some of the includes or internaly for long time...
Posted 22 February 2008 - 01:40 PM
Posted 22 February 2008 - 02:20 PM
Ye, so instead 300KB interpretator you get with Lua, you will get 20MB app. Thanks, but no thanks and I am sure nobody wants that.
Anyway, if designed correctly, any language could be used as said by Laszlo. Lua is just the best choice IMO for officialy choosen language.
You didn't understand this very well. By changing the concept of AHK internals, any language could be used, even the AHK langauge as we know it today. It will just allow the usage of other languages,
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
Your inovative hotkey syntax wouldn't be lost, it would probably stay the same.
Lua is made for non-programmers. With it you would have less hassle then with currently very poor language. Maintaining and improving the language while you also maintain and improve functinality is double work. Language theory is story per se, and it requires dedicated people who wil care about that all the time. Chris is reinventing the weel here.
hris should continue to focus on developing for the current audience of non-programmers who want to get around Windows with the least hassle.
It seems that people here don't understant one very important thing - introducing flexibile and more powerful langauge, dosn't neccesseraly mean that it will introduce bigger complexity of every day projects (special projects are always easier and understandable in more flexibile languages - just check out some of the Seans COM work to see how ugly AHK can be on low level). Also, this will make AHK much easier portable to other platforms. There were lots of ppz around who were saying things like "if we add namespaces or classes this will become bloated as Java", but Lua is good example that its not true. Its size is around 100KB, its very fast, and have all advanced concepts like mainstreem languages. You can even keep command like syntax as of its flexibile token analyzer that you can override, for instance instad:
MsgBox ("bla bla")you can allow things like
MsgBox "bla bla"This is for instance how you can write it in Python.
You can litteraly have the same simplicity you have today, in environment that allows for all kind of imaginative things.
That Lua is also targeting non-programmers, you can see by the fact that most modern games use Lua as their macro language. Children don't have troubles customizing their gaming experience using it. This is also excelent stress test, as if Lua works like a charm in gaming environment, with all system resources allocated, then it will shine in normal computer scnearios.
World of Warcraft is probalby the best example of state-of-the-art engine driven by Lua. I doubt such sophisticated peace of software is ever created, in gaming or other domains, and that is primarly cuz of Lua.
Posted 22 February 2008 - 02:38 PM
Ye, so instead 300KB interpretator you get with Lua, you will get 20MB app.
Posted 22 February 2008 - 02:53 PM
You can just go and use Ranorex. It is available for C.
In this case, its more then unaprpopriate considering the goals and history.
Random code-monkey ? I don't agree. Random code-monkey is usualy specialised in one or 2 things, probably something mainstreem.
and it's something that a random code-monkey may be able to accomplish.