AutoHotkey Community

[Chris]

I don't want to guaranty left-to-right evaluation order in something like ++x + x*2 because I don't know of any popular languages that do so (if anyone knows of any, please let me know). Therefore, guarantying this in AutoHotkey might limit future flexibility.

In spite of this, I think the current evaluation order is unlikely to change. If it ever does change by accident (e.g. due to some optimization), the current battery of tests will alert me so that the change can be undone or documented in the changelog.

[Titan]

[Laszlo]

Titan's references don't answer the question: how strongly is expression evaluation defined?

The interesting clause is for PHP: "Left associativity means that the expression is evaluated from left to right, right associativity means the opposite". I did not see anything, though, which guaranties that all terms are actually evaluated in expressions like "0 * x * y" or "0 && x && y". The problem is most obvious in the ternary operator: "x>1 ? --x : x" If x = 0, is --x evaluated? In most implementations it is not, but the left-to-right rule would mean the opposite. This is why Python is better: it does not allow these kind of side effects, which cause many bugs, allow bad coding style and save very little in the length of the code.

Javascript is similarly vague: in the referenced pages there is no mention of a possible short-circuit (aborted evaluation). About the ternary operation it only says: "If condition is true, the operator returns the value of expr1; otherwise, it returns the value of expr2." It is still not clear if expr1 is evaluated or not, when expr2 is returned.

[jonny]

Referential transparency is only a problem in advanced, analytical programming. In almost every practical case, the behavior of side effects is well-known, as in using an assignment or increment in the middle of a purely mathematical expression. In cases where the behavior is in question, the same operation can be achieved a different way. For instance, "x>1 ? --x : x" could also be "x, x>1 && --x".

[Titan]

[Laszlo]

In many languages, like AHK, there is short circuit evaluation. It means, dependent on the value of expr1 in "expr1 && expr2", expr2 may or may not be evaluated. If it causes side effects, the result depends on the current value of expr1 *and* the SW version you use. There are compiler dependent optimizations in other languages, which might rearrange the evaluation order, or drop expressions, which don't affect the result. If possible, we ought to avoid using side effects, like x++ in expressions. Even if they work now, at a future release they might not. Simple code changes or unexpected values of sub expressions could have disastrous effects.

Titan: The ternary operator is a statement in some languages, but not in others. In AHK it is "operator" (a ternary one), returning a value, which can be used in the rest of the expression. In most languages it is not a statement, because it does not do anything with the computed value.

[jonny]

[Laszlo]

[jonny]

Give me any practical scenario where it would be convenient to use x---x or x+++x and I'll concede to your argument. That syntax is ridiculous in any language.

Unless you have other examples of harmful and undocumented changes?

[Laszlo]

x+++x looks beautiful, does not use slow multiplication and 3 characters shorter than x:=2*x+1. I was tempted to use it myself, but I think, someone actually did (maybe Titan?). It is not about harmful or harmless changes, but using undocumented features. What is ridiculous to you may be OK for someone else.

This is another topic we are not going to agree on. I consider relying on undocumented features of the language to be dangerous and bad style, you consider it OK. My argument was that you might not see a change of undocumented feature documented, so it will be hard to figure out why your old script does not work in a new AHK release. You say (if I interpret it right) that this will never happen with anything practical. We just have to leave it there, and spend our time on something more productive.

Just for fun: What does the following script do?

[jonny]

[Laszlo]

[SKAN]

[Laszlo]

[jonny]

When an operator is the first thing on a line, it's considered a part of the line above it, to make expressions more readable: