Potential priorities for v2.1

Discuss the future of the AutoHotkey language
lexikos
Posts: 9780
Joined: 30 Sep 2013, 04:07
Contact:

Potential priorities for v2.1

24 Nov 2022, 04:07

lexikos wrote:
21 Nov 2022, 17:09
v2.0 is basically in bug-fix-only mode, so if I want to do anything interesting, it will be in an experimental branch or v2.1-alpha branch.
sirksel wrote:
21 Nov 2022, 22:52
any chance you could share a sneak peek high-level of the "more interesting things" for 2.1?

These are things that I intend to prioritize for v2.1... at the moment.


Module support. Aside from the obvious benefits, I intend to prioritize this for two reasons:

1. I imagine it could be used to minimize the impact on backward-compatibility that introducing new features will have. One simple example is that right now, any script using X as a global variable would break if a new built-in class or function named X is added, because classes and functions can't be reassigned. Modules may also provide a natural boundary for language-affecting directives, such as to enable backward-incompatible language improvements within one module while allowing older code to execute as part of the same script.

2. Out of respect for the effort that Helgef went to, developing two implementations (#142, #162).

Some other features might spring up during development of modules. For instance, making the implementation more able to deal with arbitrary namespaces (module-level variables vs. global variables) may also facilitate lexically scoped variables. (A lexically scoped variable has its visibility and lifetime tied to the block which encloses it, rather than the function. This is especially useful within loops containing closures.)

The current implementation has a single global C++ object g_script, which owns all lines of code and global variables/functions, and has many other responsibilities. Parsing script code at runtime is potentially unsafe because a syntax error could effectively leave g_script in an invalid state, and this is one barrier to implementing a function for loading additional scripts at runtime. (It appears that AutoHotkey_H's addFile handles it by backing up and restoring the properties of g_script, but it does not appear to account for the possibility that an incomplete function or class is added to the global namespace.) The code would need to be refactored to properly implement modules, and at the same time it would become closer to ideal for allowing scripts to be loaded dynamically. Of course, a dynamically loaded script could itself be a module.


Structured objects, i.e. typed properties. The primary purpose is basically "struct support", but this would be more flexible than (just) having a dedicated struct type. Instances of a class with typed properties would have additional space allocated for them, coinciding with how C handles structs, so they can fill that role. The definition or redefinition of typed properties would not be permitted after creating the first instance. Aside from their use with external functions, classes utilizing typed properties could be more memory-efficient, more robust, and probably faster to initialize and delete.


Importing native functions. DllCall.Bind(Type1, , ... RetType) is a trivial way to construct a function that the script can call, without having to supply the parameter types every time; but it isn't the easiest to optimize and doesn't have much flexibility when it comes to custom types, parameter conversion and memory management. Recent betas implemented some internal changes where many built-in functions are now ordinary C++ functions with statically-typed parameters, and parameter conversion and validation is performed by some central code based on the function's signature. I intend to build on this to allow the script to construct its own script functions that call native functions, with performance closer to built-in functions and greater flexibility than DllCall. This can then be optimized to improve the performance of both built-in functions (which took a slight hit in some cases) and imported functions, by assembling machine code when the function is composed, instead of interpreting the signature when it is called.

Later, this may lead to built-in support for importing COM type libraries and WinRT APIs.


Those are the things that have most interested me recently, but there may be more:


Event queuing. Currently events are "raised" and processed by posting them to one of the script's windows. Critical claims to "buffer" events, but actually does it by trying to leave them in the Win32 message queue. This has a number of problems, such as:
  • Sometimes it backfires, such as when drag-drop is being performed in a ListView, and messages get "bounced" in and out of the queue because system code is dispatching messages and AutoHotkey is queuing them up again.
  • It is not suitable for scenarios where AutoHotkey's interpreter might be embedded in another application, with its own message loop.
  • Some events are limited to just the parameters that can fit into a PostMessage call, where additional parameters might otherwise be available.
  • It is difficult to queue events based on priority, so the current implementation just discards events of lower priority than the current pseudo-thread.
I plan to improve on it by implementing a custom queue for events; i.e. callbacks that will execute on a new pseudo-thread.


Depending on the pace of development and what release schedule I decide on, other more trivial features may be implemented, and some of this might not make it into v2.1. If I'm not making much progress on something big, I might implement something small to keep my motivation up.

I do not intend to introduce new features immediately into the stable branch as I (and Chris) did with v1; instead, there will be an alpha branch with completed features being merged into a stable release periodically, perhaps every 6 - 24 months, depending on the amount of progress.
Last edited by lexikos on 20 Dec 2022, 21:40, edited 1 time in total.
Reason: thread wording
Feather
Posts: 24
Joined: 14 Nov 2022, 02:14

Re: Potential priorities for v2.1

24 Nov 2022, 08:08

I would prefer an improvement in multithreading.
At least not the current pseudo-multithreading, or ahk_h's tls threads.
At least make the threads created by dllcall("CreateThread") not crash anymore.
lexikos
Posts: 9780
Joined: 30 Sep 2013, 04:07
Contact:

Re: Potential priorities for v2.1

24 Nov 2022, 15:43

Consider anything I have not mentioned as not a potential priority for v2.1 and therefore off-topic. Keep it to Wish List or elsewhere.
Feather
Posts: 24
Joined: 14 Nov 2022, 02:14

Re: Potential priorities for v2.1

24 Nov 2022, 16:38

Okay, if the priority you define is constant.
lexikos
Posts: 9780
Joined: 30 Sep 2013, 04:07
Contact:

Re: Potential priorities for v2.1

24 Nov 2022, 19:09

My priorities are not constant, but I will not be swayed by someone else's personal preferences, especially on topics that have been brought up repeatedly. Multi-threading is a complex topic, and AutoHotkey would have to undergo significant changes before it could be supported. When I posted this topic, I was not looking to invite discussion on anything and everything that someone wants in the program. That's what the entire Wish List forum is for.
User avatar
kczx3
Posts: 1677
Joined: 06 Oct 2015, 21:39

Re: Potential priorities for v2.1

24 Nov 2022, 19:41

lexikos wrote:The current implementation has a single global C++ object g_script, which owns all lines of code and global variables/functions, and has many other responsibilities. Parsing script code at runtime is potentially unsafe because a syntax error could effectively leave g_script in an invalid state, and this is one barrier to implementing a function for loading additional scripts at runtime. (It appears that AutoHotkey_H's addFile handles it by backing up and restoring the properties of g_script, but it does not appear to account for the possibility that an incomplete function or class is added to the global namespace.) The code would need to be refactored to properly implement modules, and at the same time it would become closer to ideal for allowing scripts to be loaded dynamically. Of course, a dynamically loaded script could itself be a module.
Could you clarify this for me? Specifically, if whether the support for modules requires being able to “parse script code at runtime”. I wouldn’t have immediately thought that would be required. Sort of like the import keyword from JavaScript versus the import() function.

It all sounds great 😊
lexikos
Posts: 9780
Joined: 30 Sep 2013, 04:07
Contact:

Re: Potential priorities for v2.1

24 Nov 2022, 23:10

The support for modules does not require being able to parse script code at runtime. I consider the former to be a high priority, while the latter is a long term goal. While I am working on the code, the way that I implement changes is guided by both short term requirements and long term goals. If I find that the cost of implementing a function to load a module at runtime is low enough, I may implement it in v2.1; otherwise it will come later.

Having module support first may allow for a cleaner implementation and interface for functionality to load scripts at runtime. For instance:
  • Parsed "global" functions and classes would be contained within a new module and not the main script, so in the event of a syntax error, the new module can be discarded and the script is left in its original valid state.
  • Currently creating new variables at runtime isn't permitted because it would create inconsistency, due to load time optimizations and how assignments affect scope. Merging the parsed code into the main script would require creating new variables, whereas creating a new self-contained module would be no issue.
  • The module itself would provide an object-oriented interface for the parent script to access or enumerate its exports.
OpalMonkey
Posts: 18
Joined: 23 Jan 2014, 03:02

Re: Potential priorities for v2.1

25 Nov 2022, 00:03

Neat stuff! Thanks for giving us an overview of your current priorities and thoughts. I look forward to trying out the v2.1-alpha branch when it comes time.
iseahound
Posts: 1582
Joined: 13 Aug 2016, 21:04
Contact:

Re: Potential priorities for v2.1

20 Dec 2022, 12:45

On threads, is this an AutoHotkey "thread", or is it an actual thread via CreateThread?
lexikos
Posts: 9780
Joined: 30 Sep 2013, 04:07
Contact:

Re: Potential priorities for v2.1

20 Dec 2022, 21:53

I don't know how anyone could possibly think I was talking about OS-level threads, unless they are focusing only on the word "thread" and not understanding any other part of the explanation. I have adjusted the wording anyway.
iseahound
Posts: 1582
Joined: 13 Aug 2016, 21:04
Contact:

Re: Potential priorities for v2.1

21 Dec 2022, 01:00

Your previous work on callbacks and threads necessitated writing machine code, so I wasn't sure if you were referring to an OS level thread. I assumed a AutoHotkey thread would be sufficient for most cases.
sirksel
Posts: 227
Joined: 12 Nov 2013, 23:48

Re: Potential priorities for v2.1

07 Mar 2023, 04:10

@lexikos, sorry I missed this gem of a thread earlier. Thanks for answering my question. These areas of future development are fascinating. I'm particularly interested in the structs, as I have a lot of large data structures that I've designed as specialized array-type "data classes" to conserve memory. Having real native structs would be fantastic. And congrats again on the finalization of v2, after more than a decade in the making. It is an outright work of art, due to your unwavering and masterful design!
kazhafeizhale
Posts: 77
Joined: 25 Dec 2018, 10:58

Re: Potential priorities for v2.1

26 Jun 2023, 04:22

2.1 ,This function will take into consideration?
Wish func pass by reference support obj property
viewtopic.php?f=13&t=112238
lexikos
Posts: 9780
Joined: 30 Sep 2013, 04:07
Contact:

Re: Potential priorities for v2.1

28 Jun 2023, 01:24

If it's not mentioned in the first post of this thread, it is not one of my priorities for v2.1.

Return to “AutoHotkey Development”

Who is online

Users browsing this forum: No registered users and 11 guests