lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 05/10/2021 05:35, Halalaluyafail3 wrote:
Currently the concatenation operator has higher precedence than the
binary bitwise operators (<< >> & | ~). This is very unexpected, since
the addition and multiplication operators have higher precedence than
the concatenation operator. It'd make more sense and be more
consistent if the precedence of the concatenation operator was below
the bitwise operators. Lua 5.4 removed support for implicit
conversions with strings as arguments to bitwise operators, so string
concatenation as an operand of a bitwise operator will now error. Code
which overloads the concatenation or bitwise operators and uses them
such that changing the precedence will alter their behavior is likely
very rare.

Another useful change to the operator precedence is making relational
comparisons (< > <= >=) have higher precedence than equality
comparisons (== ~=). This would be less impactful than changing
concatenation precedence, but would be beneficial in a few cases. An
example would be a<0 == b<0 to see if both are negative or both are
nonnegative, which I have done a few times before. This shouldn't be a
breaking change, except for the very odd case of doing an equality
comparison on the left side of a relational comparison, and
overloading relation comparison with a boolean on the left hand side.
Even if this is seldom beneficial, I think that this change is still

I think that these changes would make the language better, and should
have minimal incompatibility issues.

What's the problem you are trying to solve here? All operator-rich languages have their own quirks for operators precedence. Lua is not different in this respect. Any change now will only change those quirks to other quirks.

Having programmed in so many languages (more than 30 for sure, from pro-level to absolute newbie with a week's worth experience) in the past ~40yrs, I have absolutely no strong feelings about that aspect of programming.

As a defensive programming approach, I almost always don't rely on precedence rules except for arithmetic +,-,*, / operators (which are almost universal). I write my expressions as short as reasonably possible without impacting readability, using extra temporary vars for intermediate results. And I use lots of extra parentheses, just in case.

If, like many programmers, you end up using many different languages in your job, it's too risky to try and memorize every precedence for every language, IMHO. Moreover, even if *you* can memorize them (*I* can't, and I don't even try), chances are that the next developer that has to maintain your code will get them wrong once in a while, causing nightmarish debugging sessions.

I vividly remember a case (~4yrs ago) where a colleague was adapting some code found on the Internet for an Arduino board controlling a small robot-car. He spent almost an afternoon trying to understand why some commands sent via an app and bluetooth didn't work the way he intended. He asked me for some help and when I saw his mods I saw some complex conditions in an if-else chain. It felt smelly. I didn't recognize an error rightaway, but I simply told him to add explicit parentheses around any subexpressions in those conditions the way he meant them to be parsed. Problem gone. I didn't even try to analyze where the exact bug was. He simply got some C++ operator precedence wrong. Who cares which.

In my book, operator precedence "misunderstandings" between programmers/programming languages is one of the most common logic error among the "stupid ones" (i.e. those not due to a misunderstanding of a complicated algorithm).

Bottom line: don't change the language, change the way you write your expressions.