Disable legacy if

[braunbaer]

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?

[jNizM]

It is already deprecated. Just use If (expression)

[swagfag]

write new scripts in v2. legacy-if is disabled there by default. u couldnt enable it even if u wanted to!

[JoeWinograd]

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

[swagfag]

bleh -1000. it wouldnt have got implemented in 2016, nor is it gonna be now in 2021+

start using v2, people

[JoeWinograd]

bleh -1000

Back at you.

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.

start using v2, people

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, Joe

[braunbaer]

It is already deprecated. Just use If (expression)

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.

[braunbaer]

write new scripts in v2. legacy-if is disabled there by default. u couldnt enable it even if u wanted to!

Not going to rewrite some 5000+ lines scripts so soon. I got work to do, not time to lose...

[swagfag]

never suggested doing that

In new scripts,

i think these kinds of scripts usually comprise exactly 0 lines

[SKAN]

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?

This works fine in V2

Code: Select all

Text := "
( LTrim Join
  Hello`n
  World
)"

MsgBox Text

and also in V1 if you fix that MsgBox

[braunbaer]

never suggested doing that

In new scripts,

i think these kinds of scripts usually comprise exactly 0 lines

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.

[braunbaer]

This works fine in V2

My mistake... I only checked the ahk V2 documentation superficially, did not go in depth yet.

[swagfag]

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

[JoeWinograd]

fiddling with the parser to implement ur #NoLegacyPls is too much work nobody would pay for

Who pays for fiddling with AHK? And who receives the payment?

considering we're tryna move on from v1 and all that

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.

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

[lexikos]

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

[braunbaer]

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]

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.

100% agreed! Not looking to change interpretation...only to get a warning.

I might implement it relatively soon (after v2.0-beta.1)

Much appreciated!

For now, you might try WarnLegacy.

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, Joe

[braunbaer]

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

Spoiler

Code: Select all

    static regex := "
    (LTrim Join
        mi)(*ANYCRLF)(*BSR_ANYCRLF)(?(DEFINE)
            (?<lcom>(?<![^ `t`r`n]);.*)
            (?<bcom>^[ `t]*/\*(?:.*\R?)+?(?:[ `t]*\*/|.*\Z))
            (?<hkkey>\w+|[^ `t`r`n])
            (?<hklbl>(?>[<>*~$!^+#]*(?&hkkey)|~?(?&hkkey) & ~?(?&hkkey))(?i:[ `t]+up)?::)
            (?<hslbl>:[[:alnum:]\?\*\- ]*:.*(?<!``)::)
            (?<hslblr>(?(?=:[^\:`r`n]*[xX])(?&hslbl)|(?&hslbl).*))
            (?<name>[\w[:^ascii:]#@$]++)
            (?<var>(?&name)|%(?&name)%)
            (?<tosol>(?>[ `t]*(?&lcom)?\R|(?&bcom))++)
            (?<contsec>
                [ `t]*\((?i:Join[^ `t`r`n]*+|(?&lcom)|[^ `t`r`n)]++|[ `t]++)*+\R
                (?:[ `t]*+(?!\)).*\R)*+
                [ `t]*\)
            `)
            (?<solcont>[ `t]*(?:,(?!::| +& )|[<>=/|^,?:\.+\-*&!~](?![^""]*?(?:"".*?::(?!.*?"")|::))))
            (?<blank>(?&bcom)|[ `t]*(?&lcom)?\R)
            (?<vline>.*(?>\R(?&blank)*+(?:(?&solcont).*|(?&contsec).*))*+)
            (?<num>[-+]?(?>(?>\d+|(?=\.\d))(?>\.\d*(?:e[-+]?\d+)?)?|0x[[:xdigit:]]+))
            (?<numv>[ `t]*(?&num)[ `t]*$)
       `)
        (?&bcom)(*SKIP)(?!)|
        ^[ `t{}]*
        (?:(?&lcom)|(?&bcom)|(?&hklbl)|(?&hslblr)|(?:else|try|finally)[ `t{}]*)?
        \K(?:
            (?&var)[ `t]*=(?&vline)(*:LegacyAss)|
            if[ `t]+(?&var)[ `t]*(?>!?=|[<>]=?|<>)(?!(?&numv))(?&vline)(*:LegacyIf)|
*1*        [^;""]*?(?:""[^""]*""[^;""]*?)*\K\w+(?<!if|and|or|not|while|loop|in) +\((*:WrongSpace)|  
            #Include(?:Again)?(?>,|[ `t]+,?)[ `t]*+(?:\*i )?(?<IncludePath>.*?(?=[ `t]*(?&lcom)?$))(*:Include)|
            (?:(?&vline))(*SKIP)(?!)
        `)
*2*        (?!.*\R?;legacy)
    )"

My additions are marked *1* and *2*, those marks must of course be removed from the regex

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?

[swagfag]

its documented in the documentation
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)|

lol

[braunbaer]

Code: Select all

(?&var)[ `t]*=(?&vline)(*:LegacyAss)|

lol

Nobody knows if that was intentional

its documented in the documentation
https://pcre.org/pcre.txt

Thank you
That was helpful, although in reality my problems had nothing to do with the (*SKIP)