Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

Integrating Lua into AutoHotkey


  • Please log in to reply
38 replies to this topic
interiot
  • Members
  • 74 posts
  • Last active: May 31 2014 07:15 PM
  • Joined: 06 Nov 2005
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
  • Members
  • 1945 posts
  • Last active: Feb 08 2015 03:49 PM
  • Joined: 07 Nov 2006
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
  • Moderators
  • 4512 posts
  • Last active: May 20 2019 07:41 AM
  • Joined: 24 May 2006
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.
Posted Image

ryebread
  • Members
  • 4 posts
  • Last active: Nov 14 2011 05:27 AM
  • Joined: 11 Dec 2006
lua's structure is so good for embeding, and function is nearst for user

Tuncay
  • Members
  • 1945 posts
  • Last active: Feb 08 2015 03:49 PM
  • Joined: 07 Nov 2006
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
  • Moderators
  • 4512 posts
  • Last active: May 20 2019 07:41 AM
  • Joined: 24 May 2006

How would it look like, if really embedded?

It would look awesome.

As a command or function?

?

Is performance the only reason?

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.

Should AHK have really two independent languages inside?

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.
Posted Image

Tuncay
  • Members
  • 1945 posts
  • Last active: Feb 08 2015 03:49 PM
  • Joined: 07 Nov 2006
Thx for clarification. If I have understand it correctly, no programming in Lua is needed, if embedded to AutoHotkey? My question about

As a command or function?

was, interface of Lua integrated as a command style or as a function style?

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?

majkinetor
  • Moderators
  • 4512 posts
  • Last active: May 20 2019 07:41 AM
  • Joined: 24 May 2006
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:

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 Image

Tuncay
  • Members
  • 1945 posts
  • Last active: Feb 08 2015 03:49 PM
  • Joined: 07 Nov 2006
OH MY SHIT!!! :shock: :shock: :shock: 8) 8) :? :D

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
  • Moderators
  • 4512 posts
  • Last active: May 20 2019 07:41 AM
  • Joined: 24 May 2006
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

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 Image

  • Guests
  • Last active:
  • Joined: --

...and all things we have problem with in AHK are already there in Lua via some of the includes or internaly for long time...

...but you forgot one thing...Lua's syntax SUCKKKS...no, I'm not saying AutoHotkey's syntax is perfect, in fact it's not, but...someone needs to embed JavaScript syntax with AutoHotkey, not Lua, JavaScript...Lua uses retarded "if then else" "end"...BAD!...instead of blocks...GOOD!...it uses "and" "or" "not"...BAD!...instead of "&&" "||" "!"...GOOD!...all the things I hate are in Lua...so...no thanks...

Oberon
  • Members
  • 442 posts
  • Last active: Jul 03 2008 11:34 PM
  • Joined: 18 Feb 2008
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
  • Moderators
  • 4512 posts
  • Last active: May 20 2019 07:41 AM
  • Joined: 24 May 2006

...but you forgot one thing...Lua's syntax SUCKKKS...no, I'm not saying AutoHotkey's syntax is perfect, in fact it's not, but...someone needs to embed JavaScript syntax with AutoHotkey, not Lua, JavaScript

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.

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

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,

Your inovative hotkey syntax wouldn't be lost, it would probably stay the same.

hris should continue to focus on developing for the current audience of non-programmers who want to get around Windows with the least hassle.

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.

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 Image

  • Guests
  • Last active:
  • Joined: --

Ye, so instead 300KB interpretator you get with Lua, you will get 20MB app.

...I'm sure Lua's 100KB app could be modified to act like JavaScript syntax, without importing the full 20MB syntax...

majkinetor
  • Moderators
  • 4512 posts
  • Last active: May 20 2019 07:41 AM
  • Joined: 24 May 2006
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.

and it's something that a random code-monkey may be able to accomplish.

Random code-monkey ? I don't agree. Random code-monkey is usualy specialised in one or 2 things, probably something mainstreem.
Posted Image