In new scripts, there is no real need for supporting the legacy if syntax, which can lead to hard to track errors (Just lost an hour because of missing parentheses)
What about a directive
#NoLegacyIf
which forces all if statement to use expression syntax and eliminates the need for parentheses?
Disable legacy if
Re: Disable legacy if
It is already deprecated. Just use If (expression)
[AHK] v2.0.5 | [WIN] 11 Pro (Version 22H2) | [GitHub] Profile
Re: Disable legacy if
write new scripts in v2. legacy-if is disabled there by default. u couldnt enable it even if u wanted to!
- JoeWinograd
- Posts: 2200
- Joined: 10 Feb 2014, 20:00
- Location: U.S. Central Time Zone
Re: Disable legacy if
I'm putting a +1 on this and also suggesting that the legacy assignment operator (the equal sign) have a directive, too. Along the lines of what @braunbaer suggested, something like #NoLegacyAssign. Another idea is to augment the current #Warn, as I suggested in this forum thread more than five years ago:
Disallow the equal sign as an assignment operator
And, yes, I know that it has been deprecated in V1 and removed from V2. But, as @braunbaer said about the legacy If, the legacy assignment statement can lead to some really insidious, hard-to-find bugs in V1 code. Regards, Joe
Disallow the equal sign as an assignment operator
And, yes, I know that it has been deprecated in V1 and removed from V2. But, as @braunbaer said about the legacy If, the legacy assignment statement can lead to some really insidious, hard-to-find bugs in V1 code. Regards, Joe
Re: Disable legacy if
bleh -1000. it wouldnt have got implemented in 2016, nor is it gonna be now in 2021+
start using v2, people
start using v2, people
- JoeWinograd
- Posts: 2200
- Joined: 10 Feb 2014, 20:00
- Location: U.S. Central Time Zone
Re: Disable legacy if
Back at you.swagfag wrote:bleh -1000
All we're asking for is an option...maybe a new directive...maybe an enhancement to an existing directive. You don't have to use it if you don't want to...and I'm sure you're not the one who decides if or when it is implemented. Since I NEVER use the equal sign as an assignment operator intentionally, such as option would save me from such errors, some of which have been hard to find.
I've been happy to experiment with it while it is in alpha...and will continue to do so when it moves to beta. But I develop commercial/production software with AutoHotkey, and for that I will use production level AutoHotkey, i.e., for now, V1. Regards, Joeswagfag wrote:start using v2, people
Re: Disable legacy if
That's what I do. And all I want is the option to DISABLE legacy if statements that I have entered BY MISTAKE. Those are really hard to find errors.
I understand that the developers of AHK don't wont to invest a lot of time improving AHK version 1 anymore, but making this addition really is not a big deal. And it would really help.
Regarding the legacy assignment, there is one single situation where I find it useful: when building a variable using a large continuation section. As far as I have understood from the documentation, there is nothing comparable in AHK V2. Or am I wrong?
Maybe the best solution would be something like #legacymode off and #legacymode on, so you can explicitly activate legacymode where you need it and have it disabled in the rest of the script.
Re: Disable legacy if
This works fine in V2
Code: Select all
Text := "
( LTrim Join
Hello`n
World
)"
MsgBox Text
Re: Disable legacy if
Sorry, i suppose this should be kind of funny, but I don't understand the joke. Already when I started using AHK maybe 10 years ago, I did not use the legacy format, because I was used expression format from all other programming languages I use, and the legacy format seemed somewhat weird to me. In that sense these scripts are "new" scripts, though they have evolved through many years, they contain very few assignments and "if" statements in legacy format. I have a script that I use for my own work, which has about 6000 lines of code, and I have several customers who use mostly somewhat smaller scripts to automate their work - and they approach me from time to time with new requests. Switching to AHK 2 would be much too much work that nobody would pay for.
Last edited by braunbaer on 25 Jun 2021, 18:57, edited 2 times in total.
Re: Disable legacy if
it wasnt meant as a joke. it was meant as a matter of fact, but feel free to interpret it however u like. ur definition of "new" is rather peculiar, if i ever saw one
in a similar vein, fiddling with the parser to implement ur #NoLegacyPls is too much work nobody would pay for. considering we're tryna move on from v1 and all that
in a similar vein, fiddling with the parser to implement ur #NoLegacyPls is too much work nobody would pay for. considering we're tryna move on from v1 and all that
- JoeWinograd
- Posts: 2200
- Joined: 10 Feb 2014, 20:00
- Location: U.S. Central Time Zone
Re: Disable legacy if
Who pays for fiddling with AHK? And who receives the payment?swagfag wrote:fiddling with the parser to implement ur #NoLegacyPls is too much work nobody would pay for
Depends on who "we" is. Until V2 is production, I'm not trying to move on from V1, and I suspect there are thousands of others with the same view.swagfag wrote:considering we're tryna move on from v1 and all that
I don't know what kind of programming you do with AutoHotkey, but I have a portfolio of programs that I've built with V1 during the last 10 years. There are many reusable components, so even with "new" scripts, I use lots of "old" code. My most active current program is more than 6,000 lines of code. It has to be extremely robust, with extensive error checking, capable of being deployed to a wide variety users. When a statement returns an ErrorLevel, I check for it; when a statement can throw an error, I do a Try-Catch. The former, of course, no longer even exists in V2 ("An exception is thrown on failure instead of setting ErrorLevel. Values formerly returned via ErrorLevel are returned by other means, replaced with exceptions, superseded or simply not returned."). So, my "old" code that I use in "new" scripts will have to be rewritten for V2, to say nothing of the many libraries from other folks that I use, most of which have not been rewritten for V2.
Regards, Joe
Re: Disable legacy if
A directive which changes the interpretation of if a = b would make some v1 code incompatible with other v1 code. For brevity, I'll just say that's a bad idea.
An optional warning for legacy assignment and IF statements is a reasonable idea which would likely be simple to implement, so I might implement it relatively soon (after v2.0-beta.1).
However, this and numerous other style issues and possible errors can also be detected with static analysis - i.e. tools that interpret the script without running it. (For example, thqby's AutoHotKey2 (sic) extension for VS Code detects a number of syntax errors (in v2 scripts) in real-time and points them out immediately.) I have intended to create libraries that would facilitate the creation of such tools for several years (and have done significant work toward it, but not kept the scripts up to date with v2 syntax). I may focus on this after the beta release, such as for creating a tool to assist with updating scripts.
As for legacy assignment, most cases are trivial to detect with a regex pattern: ^ *\w+ *= (a more thorough pattern might be needed, depending on your coding style). In theory, a simple function that reads the current script could easily detect most such "errors".
In practice, a much more complex pattern is needed to detect all cases and rule out false positives. For now, you might try WarnLegacy.
Hotstrings and editor functionality (or scripts which integrate with the editor) could do more, such as automatically "correcting" assignments and IF statements.
In general, I'm not interested in v1 development, both because I prefer not to write v1 scripts and because the v1 C++ codebase has fallen far behind v2. Backporting things means working with old code, in some cases seemingly repeating work that it I've already done. Having said that, in principle I had intended to eventually backport the v2 functions and potentially other backward-compatible syntax - but after a stable v2 release, since backporting them sooner might result in yet more incompatibilities between v1 and v2 (as happened with the newer Loop sub-commands).
An optional warning for legacy assignment and IF statements is a reasonable idea which would likely be simple to implement, so I might implement it relatively soon (after v2.0-beta.1).
However, this and numerous other style issues and possible errors can also be detected with static analysis - i.e. tools that interpret the script without running it. (For example, thqby's AutoHotKey2 (sic) extension for VS Code detects a number of syntax errors (in v2 scripts) in real-time and points them out immediately.) I have intended to create libraries that would facilitate the creation of such tools for several years (and have done significant work toward it, but not kept the scripts up to date with v2 syntax). I may focus on this after the beta release, such as for creating a tool to assist with updating scripts.
As for legacy assignment, most cases are trivial to detect with a regex pattern: ^ *\w+ *= (a more thorough pattern might be needed, depending on your coding style). In theory, a simple function that reads the current script could easily detect most such "errors".
In practice, a much more complex pattern is needed to detect all cases and rule out false positives. For now, you might try WarnLegacy.
Hotstrings and editor functionality (or scripts which integrate with the editor) could do more, such as automatically "correcting" assignments and IF statements.
In general, I'm not interested in v1 development, both because I prefer not to write v1 scripts and because the v1 C++ codebase has fallen far behind v2. Backporting things means working with old code, in some cases seemingly repeating work that it I've already done. Having said that, in principle I had intended to eventually backport the v2 functions and potentially other backward-compatible syntax - but after a stable v2 release, since backporting them sooner might result in yet more incompatibilities between v1 and v2 (as happened with the newer Loop sub-commands).
Re: Disable legacy if
Thank you, this is very helpful. Including this file in the script and calling the function once at startup does the job. I understand that you are not too motivated to work on ahk 1.1, and if there are usable workarounds for problems, that is ok.
- JoeWinograd
- Posts: 2200
- Joined: 10 Feb 2014, 20:00
- Location: U.S. Central Time Zone
Re: Disable legacy if
100% agreed! Not looking to change interpretation...only to get a warning.lexikos wrote:A directive which changes the interpretation of if a = b would make some v1 code incompatible with other v1 code. For brevity, I'll just say that's a bad idea.
Much appreciated!lexikos wrote:I might implement it relatively soon (after v2.0-beta.1)
Thanks very much for that code. I already run my pre-processor to detect non-unique error numbers in all error dialogs, so it will be easy and effective to put a call to WarnLegacy in there. This will do very nicely until you implement the optional warning. As always, really appreciate your help with this. Regards, Joelexikos wrote:For now, you might try WarnLegacy.
Re: Disable legacy if
@lexikos
Thank you again for this very useful script.
I have adapted it to integrate in my debugging framework, that worked out fine.
I have also made changes to the regex, the first one works well, but for the second, I would need some help, because I don't understand your regex to 100% and there must be something I don't grasp.
The integration in my framework is done in a way that if the routine gives warning, a warning screen pops up when the program is started. Now there are rare circumstances when I want to use legacy syntax - But whenever I use legacy syntax, the warning screen pops up - I only want it to pop up when I inadvertently use legacy syntax. So I looked for a way to inform the warnlegacy script that a specific legacy statement is wanted and there should be no warning for this one. The only way I could implement successfully was to place a comment line ";legacy" AFTER the line with the legacy syntax. For that purpose I use a negative lookahead *2*, that works.
I would very much prefer to place the ";legacy" line before the legacy statement, but I could not get that to work. I could not find out where in the regex I should place a negative look behind (or what else I could do) to make the script skip a legacy statement following this line immediately.
BTW, I have searched all regex documentation available to me, but I have not found what (*SKIP) does. That may be the main reason I don't fully understand how the regex works. Can you give me a link where this regex feature is documented?
Thank you again for this very useful script.
I have adapted it to integrate in my debugging framework, that worked out fine.
I have also made changes to the regex, the first one works well, but for the second, I would need some help, because I don't understand your regex to 100% and there must be something I don't grasp.
Spoiler
The first change adds an additional warning. It happens to me (and I don't think I'm alone with this problem) to leave a space between a function name and the opening bracket of the parameter list of the function. This type of error already caused me hours of debugging. This addition finds places in the code that look suspicious in that respect. The integration in my framework is done in a way that if the routine gives warning, a warning screen pops up when the program is started. Now there are rare circumstances when I want to use legacy syntax - But whenever I use legacy syntax, the warning screen pops up - I only want it to pop up when I inadvertently use legacy syntax. So I looked for a way to inform the warnlegacy script that a specific legacy statement is wanted and there should be no warning for this one. The only way I could implement successfully was to place a comment line ";legacy" AFTER the line with the legacy syntax. For that purpose I use a negative lookahead *2*, that works.
I would very much prefer to place the ";legacy" line before the legacy statement, but I could not get that to work. I could not find out where in the regex I should place a negative look behind (or what else I could do) to make the script skip a legacy statement following this line immediately.
BTW, I have searched all regex documentation available to me, but I have not found what (*SKIP) does. That may be the main reason I don't fully understand how the regex works. Can you give me a link where this regex feature is documented?
Re: Disable legacy if
its documented in the documentation
https://pcre.org/pcre.txt
lol
https://pcre.org/pcre.txt
Code: Select all
(*PRUNE) or (*PRUNE:NAME)
This verb causes the match to fail at the current starting position in
the subject if there is a later matching failure that causes backtrack-
ing to reach it. If the pattern is unanchored, the normal "bumpalong"
advance to the next starting character then happens. Backtracking can
occur as usual to the left of (*PRUNE), before it is reached, or when
matching to the right of (*PRUNE), but if there is no match to the
right, backtracking cannot cross (*PRUNE). In simple cases, the use of
(*PRUNE) is just an alternative to an atomic group or possessive quan-
tifier, but there are some uses of (*PRUNE) that cannot be expressed in
any other way. In an anchored pattern (*PRUNE) has the same effect as
(*COMMIT).
The behaviour of (*PRUNE:NAME) is the not the same as
(*MARK:NAME)(*PRUNE). It is like (*MARK:NAME) in that the name is re-
membered for passing back to the caller. However, (*SKIP:NAME) searches
only for names set with (*MARK).
(*SKIP)
This verb, when given without a name, is like (*PRUNE), except that if
the pattern is unanchored, the "bumpalong" advance is not to the next
character, but to the position in the subject where (*SKIP) was encoun-
tered. (*SKIP) signifies that whatever text was matched leading up to
it cannot be part of a successful match. Consider:
a+(*SKIP)b
If the subject is "aaaac...", after the first match attempt fails
(starting at the first character in the string), the starting point
skips on to start the next attempt at "c". Note that a possessive quan-
tifier does not have the same effect as this example; although it would
suppress backtracking during the first match attempt, the second at-
tempt would start at the second character instead of skipping on to
"c".
Code: Select all
(?&var)[ `t]*=(?&vline)(*:LegacyAss)|
Re: Disable legacy if
Nobody knows if that was intentional
Thank you
That was helpful, although in reality my problems had nothing to do with the (*SKIP)
Who is online
Users browsing this forum: No registered users and 46 guests