AutoHotkey v2 - give it a new name

[Stamimail]

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

[nnnik]

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

[Stamimail]

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.

[nnnik]

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.

[Stamimail]

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]

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]

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]

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]

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]

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.

[vvhitevvizard]

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 (94.76 KiB) Viewed 7121 times

[Helgef]

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

Cheers.

[vvhitevvizard]

@Helgef
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.

[vvhitevvizard]

#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.

[kczx3]

Pretty sure #Requires defines a minimum version requirement.

[vvhitevvizard]

Pretty sure #Requires defines a minimum version requirement.

The point is one might want maximum version requirement to be defined, too
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]

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.

[vvhitevvizard]

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.

[nnnik]

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