TheDcoder

@junkew I tried to go through the first part of the book (Compiler Construction), I didn't have enough patience to continue reading down further. I am more of a "try and see" person, I am not sure if the book had mentioned something necessary which I am not aware of. I have worked with BNF notation before, the hard bit is constructing that by myself as a reference for AutoIt, maybe someone has already done that for me? Either way, thanks for the recommendation. I could use that book as a reference if I hit any road-blocks while writing the parser. Oh, I was not aware of that, can you point me towards the relevant documentation?

@junkew I will try, but I doubt I would end up using LLVM as it is essentially a compiler for generating machine code (which is hard to do for AutoIt)

@junkew Are you proposing to use LLVM as the backend for processing the bytecode?... I don't think I am ready to go that advanced yet, let me first get a working parser and then I can figure out producing bytecode (which is most likely going to be interperted by a program which I will write)...

There is something called KBasic, which eerily sounds similar to what you are describing: That is what I was recalling in my last post. The language itself seem to be poorly maintained... On top of that, there seems to be a successor to it called "Basic For Qt®" (Yes, including the registered trademark) Either way, both of them are not free (except for the Linux version of KBasic, which appears to be free). I am not really interested in going down the route of using frameworks just for the sake of that. With time, we can maybe even (*cough*)fork the AutoIt language to add additional features, but that is not the primary goal nor do I have the skills to do it at the moment.

I admit that it was an exaggeration, the more accurate description is "basic and common" features Is that a language? Or are you referring to the framework? I recall there being some BASIC language which was based on the Qt framework... or maybe the KDE framework, cannot recall the details at the moment.

I reckon I will I am still doing research on the best way to implement the parser, thanks for the advice, I will keep that software in my mind. That is something which is inevitable, no doubt many would miss the very convenient features Windows offers, but if you need to go cross-platform you will have to stick to the very basics. We still have awesome features like a simple easy to understand syntax which just works The idea is to not port the whole of AutoIt to Linux, that would be impossible (as several others have said earlier). The goal is to have a simple scripting language like AutoIt in Linux, so you that can write your own scripts to your own things without having to resort to complex scripting and platform-dependent stuff. Maybe I should clarify my intentions by amending my first post? I see that many people are against this simply because Windows-specific things would break...

At the moment yes, but if we could eliminate multi-dimensional arrays we could easily adopt the syntax to access nested arrays. That sounds about right to me, maybe we can draw inspiration from other high-level languages. Pointers are both a blessing and a curse, I hated them in the beginning but I love them for the flexibility they offer in C now... so I am a bit biased. But I do agree that they should not have a role in high-level languages like AutoIt.

@jchd Thanks, I understand now. Multi-dimensional arrays are tricky beasts... and it is easy to confuse them with nested arrays, I have made that mistake before 😕 There is also an ambiguity in the array definition/declaration syntax which arises due to this... maybe the solution is to not have multi-dimensional arrays and only have nested arrays (like how it works in C)? I have no idea about the pros and cons.

@jchd Thanks for listing out the limitations/bad practices related to AutoIt arrays I am not sure if this counts: Example() Func Example() Local $aArray[2] = ["Foo"] Local $aInnerArray[1] = ["Bar"] $aArray[1] = $aInnerArray ConsoleWrite($aArray[0] & @TAB & ($aArray[1])[0] & @CRLF) EndFunc Oh, that is interesting! I did not know about that before It is worth mentioning that Execute might not be able to make it into my implementation as I am designing it to be a compiled language (so when the code is actually executing, it is in byte-code form)... maybe it is possible to include the compiler to dynamically compile it on runtime but there would be some problems as the context (variables, functions etc.) is going to be modified after being compiled. I recall making a thread (or maybe even a feature request) about this, I personally think it shouldn't be that hard to implement array literals so I can add it as a special feature This is a somewhat unfortunate myth which is sort of the norm these days, but it is not the fault of the language's design I think.

@YellowAfterlife Thanks for the advice, I am already somewhat familiar with WinAPI and I plan to do most of the learning on my own, though I was planning to check AHK's source code if I couldn't get something done That is correct. As I have mentioned I would be only implementing the simple/basic and essential part of the language, avoid all platform specific stuff in the beginning. Later down the road maybe there is a possibility to selectively allow platform-specific APIs (like DllCall, ObjCreate etc.). Interesting, can you elaborate further?

The most efficient way to sell your script is to get paid first Don't transfer the script to them (even a demo version), if they really want to test it out, arrange a remote demo where the buyer can take control of the computer (could be in a VM) under your supervision. This is the simplest way to avoid getting cheated and if your product has enough demand, you would not have trouble finding customers willing to pay before they get the goods

@RTFC Thanks for the vote of confidence, I am also hoping to learn a lot of new things and gain interesting experiences when working on this project

That is okay, I prefer that too... one of the reasons I want to be able to use AutoIt in Linux Linux is pretty good for that purpose, it is easier to maintain than Windows once you have it set it up! Yeah, that seems to be the most convenient (and popular) choice for scripting in Linux, good luck with learning! Many years ago I learned python as my first proper programming language, never really took off with it... I guess I was too dumb back then and the things I wanted to do were out of my league (especially GUI). Thanks, I am trying to finish the existing freelance projects I have before beginning work. I will post updates here if I have any.

@argumentum Awesome, a few words of advice: The KDE desktop has some "exotic" behaviour by default (like opening folders with a single click), be aware that almost everything can be changed using the options, so try changing anything that you don't like, I have a few of my own customization which make it much simpler and more traditional experience. Another thing about installing programs is that in Linux you can't just download an installer and run it like how you do in Windows. Most of the distros (including Fedora) provide their own software repository with a lot of programs, the most common way to install software is via the terminal (command prompt) unfortunatley, but I think KDE comes with an app store which should provide a GUI for this, I haven't tried it but it should work. Still it is not hard to install software via the command-line, you can use this command to install Firefox: sudo dnf install firefox --- At some point in time when you would be testing, you will also be expected to use the command line to compile the alternative implementation. Shouldn't be a hard task, but just something you need to keep in mind.

@argumentum That is actually a pretty natural reaction, there are many others who also prefer GUIs over command prompt (terminal as we call it in Linux). The thing with Linux is that by itself it is not a complete desktop operating system, so it does not include things like the desktop and windowing system. So all GUIs you see in Linux are independent implementations of a desktop and window managers. It is not as bad as it sounds, because most of them follow standards which are more or less universally agreed upon in the community, there are also things like freedesktop.org who have published standards for desktop environments (GNOME, KDE, Xfce, LXDE etc.) The other thing is that most of the Linux distros use the same X windowing system, so it is the de-facto standard for windowing systems at the moment. So in reality they all play together nicely and all software should work on all of those desktops, so it is your personal preference to choose which you want to go with You can use any distro which is suitable for general computer usage, but I am using Fedora as my daily driver, and that is where I would be doing my development. I can recommend Fedora, you can try out their many offerings of alternative desktop environments: https://spins.fedoraproject.org/ Fedora's primary desktop is GNOME, which is somewhat different to what you are used in Windows. If you want to feel at home with the desktop, I would recommend KDE or Cinnamon. Personally I have used many desktops over the years (GNOME, LXDE, KDE, Xfce etc.) but currently I am running KDE because I like the way it handles the GUIs... it is similar to Windows to an extent. Cinnamon is also a very good choice I recommend you take them for a spin, you can download the ISO image for each desktop and write it to a pen drive, then use try it out live, without effecting any files on your computer... a pretty handy feature

Try: Content-Type: text/html https://www.wikidata.org/wiki/Q8811#P1163

@Earthshine Good find, it is a transpiler which compiles AutoIt into C code (if I understood it correctly). It does have its advantages and disadvantages, but I believe this strays away from my main aim to provide an alternative cross-platform implementation of AutoIt in a single executable I do agree that if @scintilla4evr (or anyone else) were to extend it furthur and make it cross-platform then it would be an great thing which is perhaps more useful that the interperter I am making.

Thanks @argumentum! Hopefully I will be able to get out a working version. I am trying to figure out a good method to parse the code, when I have a somewhat clear picture of how the parser could work, I could maybe start writing code for it. P.S Finally! Feels good to have some encouragement from someone who is not TheSaint

@iamtheky Not a fan of paying for courses which teach programming... and I just looked at Ruby on Rails, the first thing that caught my eye is how web-centric it is, the introductory paragraph says That is not what I am looking for... and it looks fairly complex anyway, not something I would recommend for causal programming or as a good starting point for beginners I was busy with something else when I was replying, and that phrase didn't really strike me as something that is a related material, so didn't bother looking into it further. Funny you should say that as I am replying to each and every suggestion that I am receiving here... and if you had made the effort to read my replies, it would have been clear that what you have recommended has already been mentioned and that I am not looking to go down that route. ...Oh well, I guess we can all be sometimes lazy

@TheSaint Thanks for pointing that out, I made a mistake and overlooked the part where jchd said that AutoIt's strength wasn't its language. I have clarified my response by editing my original post. Again, thanks for noticing . @iamtheky The syntax for most programming languages will at one point be familiar (I know from experience), so not sure about the point you are trying to make... and please explain the later part of the post, I did not understand it I am afraid: Is "Rails for Zombies" an idiom that I am not familiar with?

@jchd Ah, so essentially you are recommending me to make a cross-compiler which would produce output in another language... so that it can be compiled/run in that language. I understand now There have already been several attempts to create essentially which are code converters, I don't really want to go down that path... since I will have to learn those languages too. Easier for me to write an interperter which perform the actions itself. Depends on your definition of full-blown I guess, I am aiming for a very basic compiler which would produce byte-code which the interperter can later use to execute the script.

Very true, couldn't agree with you more on that. I have no idea what I was thinking when I wrote the original response, but I somehow seemed to have overlooked the fact that you stated AutoIt's strength wasn't the language per se. I still agree that AutoIt has a very rich collection of UDFs, but the language is also a fundamental strength... which allowed those UDFs to be written in the first place I reckon. The language is what drew me into it, I only discovered about the UDFs later. You are right about WinAPI, but my goal is not to port the whole of AutoIt, but rather make an implementation of it with the subset of features which are portable and not dependent on WinAPI (like COM, GDI+ or GUI). The good thing about GUI is that we can essentially implement an UDF for backward compatibility which would deal with the native GUI implementation that I would be using if we ever get to that stage. Thanks for the suggestions in the end but can you clarify what you mean by this?:

@Earthshine I appriciate your opinion, though I felt like responding to your opinion to clarify my point of view, nothing more

@Earthshine I have already tried a good amount of those new languages, I don't want to deal with their own intricacies while using the language... each and every one of one them tries to be more than a simple programming language, I personally prefer to stick with simpler and more independent languages as you can see. I can go by just using AutoIt or C, I don't have a need for other languages at the moment. There is no language which is simpler to use than AutoIt in Linux... both syntax-wise and usability-wise. AutoIt is just a single executable and will happily work without any dependencies, that is what makes me love it That is true in a sense if you are only using it for automation, but there are many here who also use it as a programming tool which barely touches automation.

@iamtheky While we are at it, lets not forget about the other languages which are also usable for automation... bash scripting seems to be the popular choice. You can even use NodeJS and JavaScript! That is not the point, as I have mentioned automation is not the primary goal... but rather the AutoIt language itself, there is no language which is as simple and self-contained as AutoIt on Linux... Sure, there are languages which are usable and maybe even better suited for making programs, but none of them has AutoIt's syntax and the approach towards programming, I believe this is what attracted me towards AutoIt I have myopia, but I have my glasses which allow me to clearly see what I am searching for... and those are not rose-tinted by the way