[v1.1.37.01]"Post-increment" forgets its "Post" ?

[Rohwedder]

[Moderator's note: Topic moved from Bug Reports.]

Hallo,

Code: Select all

#Requires AutoHotkey v1.1.33
Label = Text
Goto,% Label++
Text:

Why Error: Target label does not exist. ?

This is OK:

Code: Select all

#Requires AutoHotkey v1.1.33
Label = 1
Goto,% Label++
1:

[iseahound]

It's a dynamic lookup, and probably doesn't support expressions.

Should probably ask for an ALTER statement, or possibly even COMEFROM

[lexikos]

The increment operators cannot produce or consume the value "Text" because it is not a number. The result is instead "". This appears to be consistent with the documentation.

Except where noted below, any blank value (empty string) or non-numeric value involved in a math operation is not assumed to be zero. Instead, it is treated as an error, which causes that part of the expression to evaluate to an empty string.
Source: Variables and Expressions - Definition & Usage | AutoHotkey v1

@iseahound, the second code block clearly demonstrates that an expression can be used.

[Rohwedder]

The increment operators cannot produce or consume the value "Text" because it is not a number. The result is instead "".

Right, that's exactly what I expect.
First Goto to the content of Label then second (i.e. post) delete the non-numeric content of Label using the increment operator.

[lexikos]

No. For Goto to receive "Text", the expression must evalute to "Text", which means the increment operator must produce the value "Text" as its result. That would be contrary to what I said above. I spoke of the overall result of the ++ operation, not the value stored in the variable.

Again, Label++ involves a non-numeric value, and therefore "it is treated as an error, which causes that part of the expression to evaluate to an empty string." That part of the expression is Label++. Label++ evaluates to an empty string.

[Rohwedder]

Same:

Code: Select all

#Warn
Label = Text
MsgBox,% Label++ ; it is not treated as an error, but empty!

Incrementing non-numeric values is not treated as an error!
As the operator ++ is placed after the variable name, the operation (evaluation to an empty string) may only be carried out after the variable has been used by the MsgBox.

But never mind! I can live with it!

[lexikos]

Incrementing non-numeric values is not treated as an error!

It is. "Treated as an error" does not mean "displays an error dialog", especially in v1. What it does mean is explicitly stated in the same sentence which says it is treated as an error. I already quoted this.

Instead, it is treated as an error, which causes that part of the expression to evaluate to an empty string.

As the operator ++ is placed after the variable name, the operation (evaluation to an empty string) may only be carried out after the variable has been used by the MsgBox.

I think you have a fundamental misunderstanding about how the post-operators work (or imperative programming in general). Think about the impossibility of what you're saying.

The imperative nature of AutoHotkey is such that the expression must be evaluated before the MsgBox command is called. Label++ is evaluated, the result ("") is stored on the stack, and the variable is incremented. The result ("") is taken from the stack and placed into the comand's list of parameters. Only then, the MsgBox command is called. The command does not use the variable's value. It never sees the variable. It only sees the result of the expression.

The command can't be using the variable, because the variable (under normal circumstances) has already been incremented, and you want MsgBox to use the previous value.

[Rohwedder]

I have read the Wikipedia article on imperative programming (light fare compared to Kant's Critique of Pure Reason).
Only the paradigm of declarative programming was new to me - the Wishful Dream of all would-be game cheaters here.

Label = 1
MsgBox,% Label++ ; 1
Label++ is evaluated, the (pre-)result (1) is stored on the stack, and the variable is incremented (2). The result (1) is taken from the stack and placed into the comand's list of parameters.
Only then, the MsgBox command is called and shows the 1, i.e. not the incremented value.

The (pre-)result (which the MsgBox has to display here) of the post-incrementation of a variable is the value of the variable before the incrementation, i.e. the untouched old content!
In the case of a number, exactly this number, in the case of a string, exactly this string.
(But no problem, even bugs have a right to exist.)

[just me]

The command does not use the variable's value. It never sees the variable. It only sees the result of the expression.

The (pre-)result (which the MsgBox has to display here) of the post-incrementation of a variable is the value of the variable before the incrementation ...

As @lexikos said, the command never uses a value stored in the variable directly. It uses the result of the expression Label++.
If the expression can be evaluated error-free, the returned result is the previous value of the variable.
In case of an error (such as non-numeric contents) the returned result is an empty string (to indicate the error).
This kind of 'silent error handling' is one of the quirks of AHK v1. It would be better to display an error dialog.

[Rohwedder]

A silent error with retroactive effect! OK, that explains the above and this

Code: Select all

MsgBox,% True++ ; ""

as True cannot be incremented.

But does not explain the empty result of the second MsgBox:

Code: Select all

N = 0
--N++
MsgBox,% N ; 1 , i.e. --N++ works
MsgBox,% --N++ ; "" should be 0

The content 1 can be decremented and post-incremented without any error!

[just me]

Code: Select all

MsgBox,% N ; 1 , i.e. --N++ works

I doubt.

Code: Select all

N = 0
++N++
MsgBox,% N ; 1 , i.e. ++N++ doesn't work

Due to backward compatibility, the operators ++ and -- treat blank variables as zero, but only when they are alone on a line.

Seemingly, the first pre-increment/decrement returns a blank result treated as 0.

[lmstearn]

Code: Select all

++N++

Even though it is a standalone statement, it should produce a syntax error, as the docs (and the Standard) indicate they are exclusive constructs:

For example, Var := ++X increments X and then assigns its value to Var. Conversely, if the operator appears after the variable's name, the result is the value of X prior to performing the operation. For example, Var := X++ increments X but Var receives the value X had before it was incremented.

From that, it's easy to see things begin to tangle when:

Code: Select all

Var := ++X++

Using these things in certain situations (e.g. function parameters) can also lead to undefined behaviour, see Using the post-increment in function arguments and Post-Increments resulted in the same value.

Consola de la Retro courtesy Reddit's Cheat sheet of obnoxious equalities..

[lexikos]

The (pre-)result (which the MsgBox has to display here) of the post-incrementation of a variable is the value of the variable before the incrementation, i.e. the untouched old content!
In the case of a number, exactly this number, in the case of a string, exactly this string.
(But no problem, even bugs have a right to exist.)

I do not understand what is so difficult to understand about this simple sequence of events: first the increment is evaluated, then the MsgBox command is called. There is no such thing as "untouched old content" or "retroactive effect". At the moment the MsgBox command uses its parameter, there is only the current (new) value of the variable, and the result of the expression. The command uses the result of the expression, which as I've pointed out multiple times, is blank due to the non-numeric value, as documented.

Code: Select all

N = 0
--N++
MsgBox,% N ; 1 , i.e. --N++ works
MsgBox,% --N++ ; "" should be 0

Regardless of the order, if both operations were performed on the variable, it should have the same numeric value that it had before the operation, because it is being incremented by 1 and decremented by 1, or vice versa. Yet the first MsgBox shows 1, meaning that the variable was only incremented and not decremented. In other words, "i.e. --N++ works" is a mistake. It does not work. In the standalone --N++, you are never using the final result of the post-increment.

Post-++ is evaluated first, and it does not produce a variable, so pre--- cannot be evaluated. This is by design.

// DUE TO CODE SIZE AND PERFORMANCE decided not to support things like the following:
...
// -> --Var++ ; Fails because ++ has higher precedence than --, but it produces an operand that isn't
// a variable, so the "--" fails. Things like --Var++ seem pointless anyway because they seem
// nearly identical to the sub-expression (Var+1)? Anyway, --Var++ could probably be supported
// using the loop described in the previous example.
Source: AutoHotkey/source/script_expression.cpp at v1.1.37.01 · AutoHotkey/AutoHotkey · GitHub

Code: Select all

++N++

Even though it is a standalone statement, it should produce a syntax error, as the docs (and the Standard) indicate they are exclusive constructs:

I think there are three errors in your statement:

1. It is not a standalone increment statement. If the line was ++N or N++, the increment would be "alone on a line". Two increments together is not "alone".
2. The program literally cannot produce a syntax error; the author produces a syntax error, and (execution of a script containing) the syntax error produces a bad result or an error dialog. Expression syntax errors in v1 generally do not produce an error dialog, which is what I assume you actually meant by "produce a syntax error". So if this syntax is invalid, the result should be blank in v1 - and the result is blank, even if the syntax isn't technically invalid. In v2, it produces a load-time error dialog.
3. An example not covering a scenario says nothing about whether the scenario is valid or supported. The remaining part of your quote only describes the effect of post-increment, and does not indicate whether pre- and post- operators can or cannot be combined.

(--N)++ is valid and works. If N was originally 0, it sets N to 0 but returns -1. You would only see -1 if you directly used the expression, as in MsgBox % (--N)++.