AutoHotkey v2 - give it a new name

Discuss the future of the AutoHotkey language
Stamimail
Posts: 77
Joined: 06 Nov 2014, 08:48

AutoHotkey v2 - give it a new name

21 Apr 2020, 16:23

Sorry for not visiting here often,
but I just jumped in here to say:
if the AutoHotkey v2 syntax are going to be different from v1, I think it would be better to give it a different name (new language), and not to use the same name.
C
C++
C#
is better distinction than
python 2
python 3
User avatar
nnnik
Posts: 4470
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: AutoHotkey v2 - give it a new name

22 Apr 2020, 01:40

C/C++/C# are completely different languages with completely different paradigms. Saying that they are different versions of the same language is completely wrong.
In AutoHotkey the only core syntaxes that got removed is the command syntax. That change is so neglecteable in comparison to the changes between C and C++ that giving AutoHotkey v2 that name would be utterly misleading.

I think that you have a bad image of what a v2 is about
Recommends AHK Studio
Stamimail
Posts: 77
Joined: 06 Nov 2014, 08:48

Re: AutoHotkey v2 - give it a new name

22 Apr 2020, 07:37

C/C++/C# are completely different languages with completely different paradigms. Saying that they are different versions of the same language is completely wrong.
I'm not saying this. I'm saying that it is more easy to know what syntax you are talking about.
In contrast, when you say this code is Python coded, those who are unfamiliar with the language can make mistakes about the syntax (v2 or v3). I think the Python team did wrong about this.

When there is backwards compatibility, and only new features are added - I would call it v2
When there isn't backwards compatibility, and the syntax changes, I think it would better to give it a new name.

Since I'm not a developer, you're definitely right if you say I don't know what I'm talking about.
Still, I brought it up, for your decision - the developers.
User avatar
nnnik
Posts: 4470
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: AutoHotkey v2 - give it a new name

22 Apr 2020, 15:58

OK - generally speaking versioning usually goes like this:
major.minor.patch
patch - only repairs existing features and doesnt add anything new
minor - adds new features and the new version is still completely backwards compatible (only in extreme cases there is something that isnt backwards compatible)
major - removes or replaces parts of existing features (backwards compatability is not given)

The issue isnt the versioning, the issue is that its hard to see what exactly is spoken about
Same happened with the transition from AHK Basic to AHK_L (Now 1.1 and 1.0)
I can see this being a problem but there will always be people working on their software thats now a few years old still keeping it in the old version since transitioning is too much work.
Recommends AHK Studio
Stamimail
Posts: 77
Joined: 06 Nov 2014, 08:48

Re: AutoHotkey v2 - give it a new name

23 Apr 2020, 06:20

OK - generally speaking versioning usually goes like this:
major.minor.patch
patch - only repairs existing features and doesnt add anything new
minor - adds new features and the new version is still completely backwards compatible (only in extreme cases there is something that isnt backwards compatible)
major - removes or replaces parts of existing features (backwards compatability is not given)
Thank you for this.
I think it's one way to see it.
In the case of a new syntax, I think it would be wrong as it would lead to confusion.

The other way is:
minor - add minor features
major - add major features (or making a new design for a GUI)

That's my experience with programs, and I think it might be the same with programming language development.
william_ahk
Posts: 8
Joined: 03 Dec 2018, 20:02

Re: AutoHotkey v2 - give it a new name

12 May 2020, 07:07

I think Rust handles this issue nicely. While the version number is consistent, it introduces the edition system for the compiler to interpret the code in different ways for backward-incompatible syntax changes. For AHK, we can add a directive in the beginning of the script to specify the "edition" of the code. That way, old scripts won't have to change and new scripts could run as well just by specifying which edition to use without too much fuss.
https doc.rust-lang.org /stable/edition-guide/ Broken Link for safety
swagfag
Posts: 3976
Joined: 11 Jan 2017, 17:59

Re: AutoHotkey v2 - give it a new name

12 May 2020, 08:48

i can kinda sorta make this work if u bundle every interpreter released so far and switch them out dynamically. now ure looking at a default ahk installation that has ballooned up to 250MB+ and possibly beyond

fuss
iseahound
Posts: 611
Joined: 13 Aug 2016, 21:04
GitHub: iseahound

Re: AutoHotkey v2 - give it a new name

12 May 2020, 10:07

That's actually not a bad idea. Someone should collect all the old ahk.exe files, if only for archival purposes. 250 MB, even a few gigs is not a real cost these days. Have you ever tried npm install lmao.
william_ahk
Posts: 8
Joined: 03 Dec 2018, 20:02

Re: AutoHotkey v2 - give it a new name

13 May 2020, 07:15

swagfag wrote:
12 May 2020, 08:48
i can kinda sorta make this work if u bundle every interpreter released so far and switch them out dynamically. now ure looking at a default ahk installation that has ballooned up to 250MB+ and possibly beyond

fuss
We could just bundle the major versions that are not backward-compatible like v1 and v2. It would be great if AutoHotkey can support this officially.
Evermind
Posts: 1
Joined: 26 Jun 2020, 23:29

Re: AutoHotkey v2 - give it a new name

26 Jun 2020, 23:53

swagfag wrote:
12 May 2020, 08:48
i can kinda sorta make this work if u bundle every interpreter released so far and switch them out dynamically. now ure looking at a default ahk installation that has ballooned up to 250MB+ and possibly beyond

fuss
Hello, I just came this forum to express my experience of unable to distinguish scripts of 2 incompatible language version (v1 and v2). It's painful to handle this, because scripts of the 2 incompatible language versions are all put in script files of same extension(*.ahk), thus it cannot be distinguished by its file ext; And thus cannot be distinguished by the interpreter which is associated with the extension(*.ahk). Only one of V1 and V2 interpreters can be registered to associate with *.ahk, so when I have scripts of both language versions(which is almost sure to be true, because I have to find needed scripts of both versions on internet), I can only make one half of them work, and another half will be run by incompatible interpreter.
IMHO this is the root cause: 2 (or more in the future) incompatible interpreters cannot distinguish corresponding scripts.

So to the solution. We could make version 2 script have different extension (*.ahk2), but this is unexpandable because in this way we could expect *.ahk3, *.ahk4, etc.

So I suggest adding prompt of exact language version in script. The prompt is at first line of script and it looks like:

Code: Select all

;# language: v1
or

Code: Select all

;# language=v2
, or the like.
which is a special comment which tells interpreter which version the script is written in. And if it's missing, then it defaults to v1.
And to the interpreters. Now we could install 2 versions of interpreters parallelly without conflict, except for file extension registration; To resolve this we could add a little frontend module which knows every installed interpreters and assotiate with *.ahk and is actually invoked when running a script, and it checks the version prompt at 1st line of script, and invoke corresponding interpreter accordingly. To those existing scripts without version prompt, the frontend module even could guess actual version of script and invoke correct interpreter.
User avatar
vvhitevvizard
Posts: 405
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: AutoHotkey v2 - give it a new name

28 Jun 2020, 11:35

Using a commented first line like a meta info is a good idea! We should just standardize its format and start using it beforehand. All my scripts have first line commentary like

Code: Select all

;v1.7 date | AHK v2-112
At least it helps maintaining scripts mentioning what was the last AHK version the script was tested with.

As for now I just exploit .ahk2 extension for AHK V2 scripts. But I don't use AHK installers. I use internal Total Commander's associations. And also a bunch of renamed AHK V2 interpreters in conjunction with Total Commander`s button bars for activating any AHK version I like for a file under the cursor. All the environment stays truly portable w/o polluting the system with different AHK installations:
Clipboard01.png
Clipboard01.png (94.76 KiB) Viewed 3341 times
Helgef
Posts: 4459
Joined: 17 Jul 2016, 01:02
Contact:

Re: AutoHotkey v2 - give it a new name

28 Jun 2020, 12:24

I'm not sure if this is on topic, but lexikos have implement :arrow: #requires.

Cheers.
User avatar
vvhitevvizard
Posts: 405
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: AutoHotkey v2 - give it a new name

28 Jun 2020, 13:13

@Helgef
:thumbup: It wouldn't guarantee any script compatibility for now tho: a script written for v2-212 might fail with v2-211 and v2-213 but having a standardized legal command is a great yes yes yes. I like syntax. And who knows one day AHK v2 might "learn" how to run old version scripts by doing some substitutions on the fly at loading time. Such lenient AHK builds allowing a wider range of supported script versions would be good for assessing other people scripts written for different version before correcting code for the most modern and strict and optimized syntax.
Just mark my words, first step would be to implement the simplest preprocessor and macro engine. And then it might even be user scripts for preparing a proper code for the current AHK version on the fly. I do know all the endeavors trying to make AHKv1->AHKv2 working converter failed afaik because its required to convert the script as a whole w/o knowing all the script logic nuances and quirks. Now imagine the script's author makes a special preprocessor routines to have his script modifying itself to be ready for both v1 and v2 AHK versions.
User avatar
vvhitevvizard
Posts: 405
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: AutoHotkey v2 - give it a new name

16 Jul 2020, 20:24

Helgef wrote:
28 Jun 2020, 12:24
#requires
I can't apprehend what syntax is required to make some special script version run ONLY with the exact alpha version. I tried

Code: Select all

#Requires AutoHotkey v2.0-a103
But it still runs on V2-a116 w/o that special warning/error.
Also, request: ability to set a range, e.g. v2.0-a103, v2.0-a107 with comma or just whitespace between version numbers.
User avatar
kczx3
Posts: 1148
Joined: 06 Oct 2015, 21:39

Re: AutoHotkey v2 - give it a new name

16 Jul 2020, 20:57

Pretty sure #Requires defines a minimum version requirement.
User avatar
vvhitevvizard
Posts: 405
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: AutoHotkey v2 - give it a new name

16 Jul 2020, 21:05

kczx3 wrote:
16 Jul 2020, 20:57
Pretty sure #Requires defines a minimum version requirement.
The point is one might want maximum version requirement to be defined, too :D
My use case I'm in the middle of upgrade for some code chunks and I do know exactly what AHK versions the current code is compliant with (I upgrade it gradually and have different versions side by side).
Requirement is to limit it to exact alpha versions or range of them.
I want the script to show a strict [range] requirement error at loading-time instead of some random errors in case I accidentally run it with wrong AHK host version. Also note that I can't use runtime checkups with A_AHKVERSION for that purpose.
SandyClams
Posts: 2
Joined: 02 Jul 2020, 11:55

Re: AutoHotkey v2 - give it a new name

16 Jul 2020, 21:16

vvhitevvizard wrote:
16 Jul 2020, 21:05
Requirement is to limit it to exact alpha versions or range of them.
why not just use FileGetVersion and write your own test function? All the v2 binaries (that I've seen at least) have the specific build listed in their metadata.
User avatar
vvhitevvizard
Posts: 405
Joined: 25 Nov 2018, 10:15
Location: Russia

Re: AutoHotkey v2 - give it a new name

17 Jul 2020, 02:07

SandyClams wrote:
16 Jul 2020, 21:16
why not just use FileGetVersion and write your own test function? All the v2 binaries (that I've seen at least) have the specific build listed in their metadata.
#requires is a preprocessor command that activates at the script loading time. It activates before runtime, before other lines following it got even parsed.
filegetversion is a runtime function. A script started with a wrong host version would simply have failed with a random error before that line got executed.
Also, the purpose is not to have an additional chunk of runtime code that checks host interpreter's version - we've got preprocessor #requires directive which needs to be extended now.
User avatar
nnnik
Posts: 4470
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: AutoHotkey v2 - give it a new name

18 Jul 2020, 03:57

#Requires AHK200a103-AHK200a106
Perhaps a Tweak of this syntax offers the flexibility we look for.
Recommends AHK Studio

Return to “AutoHotkey v2 Development”

Who is online

Users browsing this forum: No registered users and 4 guests