(Poll) What features do you wish you had in AutoIt?

[TheDcoder]

Hi everyone,

The question is simple, what features do you wish you had in AutoIt? AutoIt is a great language but it comes with limitations, so I am on a mission to write a similar scripting/programming language with many improvements which would make it a very powerful but easy-to-use tool.

As some of you already know, the project is already underway and it is called EasyCodeIt.

I am interested in seeing what features are the most wanted so that I can focus my attention to them in the near future

So please help me by voting for your favorite features!

Edited July 20, 2021 by TheDcoder

[argumentum]

1) Cross-platform support. Yes, that'd be cool. But there is Java, etc.
2) Multi-threading. Yes but, sounds better than it is for script kids ( like me ).
3) Compilation to machine or byte code. Yes but, it'd be a language like C, R, etc., rather than an automation tool.
4) Modular programs. Yes if you're gonna build machine code, otherwise, meh.
5) Other (Please mention which by posting). Ok:
Internal IPC for easy forking. ( a semaphore system would also be welcomed )
A queued storage system, much like MailSlots ( could be used with the IPC or as IPC ) TCP driven and/or memory, if possible.
The above internal goodies would benefit of separate threads, as also GUI would benefit if in an independent thread, as to not freeze the code from running due to clicking or IPC or anything internal ( But that don't mean to expose threads to users. Users can fork. )
A hook to OpenSSL or, if machine code gen., a SSL module, or both ( Crypto is important ).
A chromium integration ability.

I guess that's enough for a wish list

PS: byte code or not, the above is what I'd like to see in an AutoIt.

[TheDcoder]

3 hours ago, argumentum said:

1) Cross-platform support. Yes, that'd be cool. But there is Java, etc.

Java is not a fair comparison, it is a cross-platform OS which happens to run on top of other OSes, and the whole OS just runs one program

I might be "let's make a programming language" crazy but I am not "let's make an OS" crazy

3 hours ago, argumentum said:

3) Compilation to machine or byte code. Yes but, it'd be a language like C, R, etc., rather than an automation tool.

Not really, python for example compiles the code into its own bytes before interpreting it, I am taking a similar approach. If I ever get around making an actual compiler, it would just be a little bit of generated assembly with a lot of pre-compiled stubs to handle high-level stuff

3 hours ago, argumentum said:

4) Modular programs. Yes if you're gonna build machine code, otherwise, meh.

Some of the sub-systems might get too heavy (10s of MBs) if I implement all the other features you asked for, so it's a good feature to have, hopefully not too bothersome to implement

3 hours ago, argumentum said:

5) Other (Please mention which by posting). Ok:
Internal IPC for easy forking. ( a semaphore system would also be welcomed )
A queued storage system, much like MailSlots ( could be used with the IPC or as IPC ) TCP driven and/or memory, if possible.
The above internal goodies would benefit of separate threads, as also GUI would benefit if in an independent thread, as to not freeze the code from running due to clicking or IPC or anything internal ( But that don't mean to expose threads to users. Users can fork. )
A hook to OpenSSL or, if machine code gen., a SSL module, or both ( Crypto is important ).
A chromium integration ability.

Those are great recommendations, I already had some of them in my mind, like hooking into crypto functions (OpenSSL in Linux). These features are more related to a standard library though, as opposed to the core language design itself, but I am glad you mentioned them anyway.

I have a lot planned for which would go into the standard set of tools available in EasyCodeIt, here are some I can recall on top of my head:

1. cURL integration to support a lot of network protocols
2. Transparent encryption for network sockets (the crypto SSL stuff you mentioned), perhaps implemented via a generic abstract layer so that people can implement their own wrappers over sockets and other IO
3. A lot of wrappers around POSIX, Linux, Windows and other platform specific stuff
4. etc.

As you can see, implementing all of this in a single program might make it too heavy, thus my interest making it somewhat modular.

Not really sure about chromium though, that might be taking it a bit too far... but we will see, nothing is impossible*!

^{*conditions apply}

[RTFC]

Compiliation to machine or byte code: to me, only the former would make sense. Especially re. file I/O (and array/list/queue-related stuff), AutoIt is IMHO several orders of magnitude too slow for handling large data sets.

Other: two things immediately come to my mind:

1. memory management: user control over how much memory (virtual or otherwise) a particular process can (pre)allocate
2. boost integration: boost is OS-agnostic out of the box, and an excellent, rock-solid, well-documented, all-round support library package (no need to reinvent the wheel if boost already has...)

[JockoDundee]

Other: in no particular order 

1) Allow assignments during evaluation:

While $result=GetResults()

 ProcessResult($result)
 
WEnd

2) Variables with file scope 

3) Objects

4) Reflection

5) Parameter passing by name 

AFunc($b =: 5)

Func AFunc($a = 0, $b)

EndFunc

6) One-line ElseIf

If $a=b Then AFunc()
ElseIf $a=$c Then BFunc()
ElseIf $a=$d Then CFunc()
Else DFunc()

7) Cast to boolean - Bool()

8 ) Structs

9) Return multiple values from function

 

[jpm]

5) has been already submitted to Jon long time ago

[kcvinu]

• No need for cross platform support. Please don't waste your precious time.
• Multithreading is a must.
• If possible, please support object oriented programming. If it is not in your radar, please add support for struct and constructor. Most OOP tasks would be done with a struct with constructor. 
• A container data type (List) is a must have item. 
• If your target OS is windows, you can use win32 api for a GUI library. No need for a visual designer. If code is simpler, users can easily create a gui with code.
• Modularity is a must have item. 
• Please avoid the dollar sign from variable name.

Edited July 20, 2021 by kcvinu

[JockoDundee]

14 minutes ago, kcvinu said:

Please avoid the dollar sign from variable name.

Warning - Script breaking change

[JockoDundee]

9 hours ago, jpm said:

5) has been already submitted to Jon long time ago

Thx.  What about file scope for variables, did that come up often?

With the heavy reliance on UDFs by AutoIt, which necessitate the namespace sharing of globals between unrelated modules, I would think it would.

Also, I naively imagine such a change to be backward compatible, and relatively straightforward to implement, by just prepending some unique magic string (based on the file name) to the file local declaration and references within each file.

What could go wrong?

[TheDcoder]

Looks like I have a lot to respond to 😅

16 hours ago, RTFC said:

Compiliation to machine or byte code: to me, only the former would make sense. Especially re. file I/O (and array/list/queue-related stuff), AutoIt is IMHO several orders of magnitude too slow for handling large data sets.

Other: two things immediately come to my mind:

1. memory management: user control over how much memory (virtual or otherwise) a particular process can (pre)allocate
2. boost integration: boost is OS-agnostic out of the box, and an excellent, rock-solid, well-documented, all-round support library package (no need to reinvent the wheel if boost already has...)

I understand advantages of machine code, but can you elaborate on why you think byte code wouldn't make sense? It allows the interpreter to function without parsing the same old code on every execution, aside from the obvious benefit of cutting down on the code required for the parser itself.

Byte code would also serve as a good intermediate between pure machine instructions and pure script interpretation, perhaps it can later be used by different compilers which could target different instruction sets

This is important in our "smart" "IoT" connected world, where many small devices use ARM or some other instruction-based processor, x86 is very rare outside of personal computers I think.

--

About memory management, I am not sure I entirely understand what you mean, do you want to be able to set a hard limit on the amount of memory the process can use?

Boost: I looked at it and it is indeed a very good library, but an awful lot of it seems to be very specific to C++, in fact one of their goals is to get these functions integrated into standards... and integrating with it means also following same mindset as C++, which is something I really want to avoid at all costs, I'd say it would be an anti-goal.

A large part of the library deals with C++ language features, only a few actually provide useful "end-user features" like dates, filesystem, http etc.

So even if we wanted to integrate with boost ignoring the other stuff, the benefit isn't that much... and there are better libraries which can provide support for these kind of things anyway. Even in C++ there is Qt which provides everything a desktop programmer could ever want, and there is already a BASIC language which integrates with it

@JockoDundee

16 hours ago, JockoDundee said:

1) Allow assignments during evaluation:

For sure! This is one of the features I had planned from the start, you will be able to use assignment in expressions

I might also add an additional operator, something like python's := to make it more explicit.

16 hours ago, JockoDundee said:

2) Variables with file scope 

File scope as in variables which are not shared across includes? This suggestion sounds good on the surface but it has several issues, #include is treated as a "copy-and-paste" inside the scanner/tokenizer, so it is completely transparent to the syntax analyzer (the actual parser).

We could make the parser more complex by adding the ability to recognize the file boundaries and then implement file scope that way but I am not sure if that is a wise design decision.

A more appropriate feature might be namespaces, which you have mentioned in your latest post

16 hours ago, JockoDundee said:

3) Objects

4) Reflection

8 ) Structs

Objects is an ambigious term, it can be a misnomer, one of the meanings is just a term for any value... but I guess you are talking about them in the context of "Object-oriented programming", I might implement an "object" in the form of a structure (simply a variable which contains a fixed number of elements which can be referred by names, very similar to maps/associate arrays).

Reflections if I am recalling correctly are traps for operations on a variable/object, it is an interesting prospect for sure

16 hours ago, JockoDundee said:

5) Parameter passing by name 

Good one, noted!

16 hours ago, JockoDundee said:

6) One-line ElseIf

Another one of the things I had in my mind from the start, I think I made a topic here in the forums requesting the feature. Rest assured this will make its into ECI

I am trying to keep whitespace as less significant as possible, some might be opposed to the idea but I would prefer flexibility as it offers a chance to write code in a less awkward way in certain situations while maintaining the usual norms in normal circumstances.

16 hours ago, JockoDundee said:

7) Cast to boolean - Bool()

Doesn't AutoIt already have this feature? It's simple enough to DIY too:

Func Bool($vVar)
    Return Not Not $vVar
EndFunc

But yeah, casts are useful.

16 hours ago, JockoDundee said:

9) Return multiple values from function

How would this be different than returning an array?

4 hours ago, kcvinu said:

No need for cross platform support. Please don't waste your precious time.

In my opinion this is one of the most important features of a high-level scripting language, having the ability to use it everywhere. Not saying that it would be a "Code-once run everywhere" thing, but the fundamentals would stay same and the programmer can handle platform specific stuff with their code.

4 hours ago, kcvinu said:

If possible, please support object oriented programming. If it is not in your radar, please add support for struct and constructor. Most OOP tasks would be done with a struct with constructor. 

AutoIt is definitely not meant for OOP, some may not agree but I think in spirit it wouldn't be AutoIt if we add OOP to it. Objects are okay, but not a full-fledged inheritance system

4 hours ago, kcvinu said:

A container data type (List) is a must have item. 

Sounds like an array, python calls them lists. I think you might be referring to something more than an array, so can you elaborate?

4 hours ago, kcvinu said:

If your target OS is windows, you can use win32 api for a GUI library. No need for a visual designer. If code is simpler, users can easily create a gui with code.

GUI is another beast, and of course a visual designer is a hard thing to make. I am not in an hurry to implement this.

Eventually I will implement GUI with support for layout-based design, similar to how HTML and GTK work, as opposed to absolute pixel position based design (this would still be possible if needed)

4 hours ago, kcvinu said:

Please avoid the dollar sign from variable name.

Sorry, if we did this it won't be AutoIt

Does any BASIC dialect support this feature actually?

--

Wow, this might be my longest reply post.

[JockoDundee]

1 hour ago, TheDcoder said:

Reflections if I am recalling correctly are traps for operations on a variable/object…

Autoit already has some reflection, like vargetype.  But one thing missing is function stack info.  Heck you can’t even tell what function you’re in at the top level. 

1 hour ago, TheDcoder said:

File scope as in variables which are not shared across includes? This suggestion sounds good on the surface but it has several issues, #include is treated as a "copy-and-paste" inside the scanner/tokenizer, so it is completely transparent to the syntax analyzer

Yes.  But I argue it’s trivial to implement as a simple file preprocesser which essentially prepends a unique token on file local variables thru out the file.  It’s self contained.  But namespaces is even better.

1 hour ago, TheDcoder said:

Doesn't AutoIt already have this feature? It's simple enough to DIY too:

Don’t think it does, but I DIM too.

Edited July 21, 2021 by JockoDundee

[TheDcoder]

1 hour ago, JockoDundee said:

Autoit already has some reflection, like vargetype.  But one thing missing is function stack info.  Heck you can’t even tell what function you’re in at the top level. 

Hmmm... maybe I don't fully understand these reflections you are talking about. Anyway, exposing too much info about the execution will prevent optimizations, like making the function stack publicly accessible. I don't see much benefit anyway, you should stick to parameters for passing around info, keep it simple

However a macro with the current function name is reasonable, it can be useful for debugging purposes.

1 hour ago, JockoDundee said:

Yes.  But I argue it’s trivial to implement as a simple file preprocesser which essentially prepends a unique token on file local variables thru out the file.

Yeah, I guess it could work that way.

1 hour ago, JockoDundee said:

Don’t think it does, but I DIM too.

That's crazy, I didn't know AutoIt converts both datatypes to a number in a mixed comparison... but that won't be the case in ECI, I will make the comparison purely binary, which means an empty string and zero will always be false AND a non-empty string and non-zero will be true.

Honestly don't know why it isn't implemented like that in AutoIt, what's the point of an extra step of conversion?

Edited July 21, 2021 by TheDcoder

[TheSaint]

11 hours ago, kcvinu said:

Please avoid the dollar sign from variable name.

Why? It's a fantastic visual assist and makes for faster reading and especially troubleshooting ... no doubt why it was implemented.

[TheSaint]

On 7/20/2021 at 10:02 AM, TheDcoder said:

Modular programs (compiled files will only contain required modules like Networking etc. instead of everything)

Isn't that already achievable to a large degree with Includes, especially as I recall unwanted elements are stripped out during compiling?

Or am I missing something? Maybe you are just referring to what is wanted for EasyCodeIt and not the status of AutoIt.

[TheDcoder]

1 hour ago, TheSaint said:

Isn't that already achievable to a large degree with Includes, especially as I recall unwanted elements are stripped out during compiling?

I think you are referring to the unneeded code which is stripped by AutoIt3Wrapper script written by Jos. I was not talking about that, I was talking about the interpreter program itself, AutoIt for example always includes a full copy of AutoIt3.exe in all compiled programs.

My proposal is to only include the required components instead of everything in the compiled program

[Earthshine]

that is what I thought he was doing.. lol, gathering input specs for EasyCodeIt, but who cares, I voted. Do it up. If EasyCodeIt had all that stuff too I would use it on Linux if I ever migrate. My dev and work stuff would never care... I might because I don't like win11 really all that much.

Edited July 21, 2021 by Earthshine

[TheSaint]

1 hour ago, TheDcoder said:

I think you are referring to the unneeded code which is stripped by AutoIt3Wrapper script written by Jos. I was not talking about that, I was talking about the interpreter program itself, AutoIt for example always includes a full copy of AutoIt3.exe in all compiled programs.

My proposal is to only include the required components instead of everything in the compiled program

If I read you right, you are saying that AutoIt3.exe itself includes unwanted elements?

But even if so, and you are talking about only using part of AutoIt3.exe, why in this day and age does it really matter? In the end it is only a size issue isn't it? And we have huge storage capacities now, that a few hundred kilobytes is almost nothing. And download speeds and capacities have also grown hugely.

Far better to spend your developing time on stuff that will really make a practical difference, i.e. multi-threading.

[Earthshine]

it matters because because it scales well and debloats the output. it matters on large scales stuff. He's a perfomance guy... that's a good thing in my book. He's talking about a smart linker that only pulls what's necessary into the executable so it's not a fat, bloated piece of software

[jchd]

In no particular order, without changing the fundaments of the language:

1. Some form of file scope for variables (and functions?) or namespaces. E.g. in a source file, Restrict $a = 12345 would declare a variable $a for this file only.
2. Ability to read/write any subarray: say we have $a[3][2][4], then $a[1][0] would evaluate to the 1D array formed by $a[1][0][0..3]. $a[1] would eval to the 2D subarray $a[1][0..1][0..3]
3. Ability to create arrays from a text statement using Execute (like https://www.autoitscript.com/trac/autoit/ticket/3702)
4. Ability to pass blank arguments to functions (that or named arguments): fct($a, , "abcd", , 47) would mean fct($a, Default, "abcd", Default, 47)
5. Extend the max number of cells (currently 2²⁴) in an array, possibly using a pragma
6. Atomic exchange of 2 variables (including array elements or sub-arrays) without having to make 3 copies with intermediate variable: $a >< $b
7. Lists + list functions
8. Ability to modify the actual element that the running variable $x represents in For .. In constructs: For $x in $aArray  ...  $x! &= "abc"  would apply to what $x currently "points to", while $x &= "abc" would only change $x locally and not the array element (as it currently does).
9. Allow assignments during evaluation (as previously mentionned)

... to be continued!

[argumentum]

yeah, don't add something that can be gotten by a UDF. Like @OSVersion. That way you can future proof the product.
If there could be UDF updates separate from the meat'n'potatoes, ..less work for the coder and more work for the community. One would not limit the other. 

Note: in AutoIt, doing an anthropological historical study, @OSVersion was needed at the time, then kept ( my 2 cents. )

Edited July 21, 2021 by argumentum
clarification, ....maybe :)