This here seems like a very good idea and I hope other languages in active development take note. And als JS’ Prettier, which actively removes parentheses like these.
Lisp because everything is explicit and only the form just inside an opening parenthesis does anything. APL as all is scanned right to left.
E.g. 1 & 2 == 0:
Python => True
C => 0 (False)When read procedurally (left to right) it is quite okay though, and no parens are needed (but could be added).
The catch is that `1 + 2 * 3` becomes 9 instead of 7 as math eyes expect. I guess there are things to unlearn and unlearning is always hard. But consider the rules other languages have, like C regarding signed and unsigned, and Javascript regarding comparisons, compared to them this is almost trivial.
Except that there are almost no circumstances in which "((a & b) + c) >> d" is a sensible expression. The only reasonable interpretation is "(a & b) + (c >> d)", and even then that plus is suspicious.
In practice, the worst offenders are "a & b >> c" and "a & b << c". The first expression is usually intended to mean "(a & b) >> c" — it's a bitfield extraction; the second one is usually intended to mean "a & (b << c)" — it's clearing of all but one bitfield. As you can see, those semantics are impossible to achieve with << and >> having the same precedence.
slct(var, 6, 2) = expr; // var = (var &~ (0b111111 << 2)) | ((expr & 0b111111) << 2);
var = slct(expr, 6, 2); // var = (expr >> 2) & 0b111111;
> Except that there are almost no circumstances in which "((a & b) + c) >> d" is a sensible expression.
That doesn't seem like a convincing argument to me. The question is whether or not the rules set you up for scenarios where misunderstandings are likely. Strict left to right does not - for example, given a & b << c it is immediately clear that the desired interpretation is not the actual one while b << c & a will unmistakeably do what you want.
No, this is a misleading statement of the problem because it tacitly assumes that programmers write arbitrary expressions with almost the same probability, so the rules should accommodate them all, at the same expense. This is patently false, and is a horrible policy for any UI/UX/DevEx/etc. designer. The very existence of linters and static analyzers, hell, even the warnings in the modern compilers about suspicious operator precedence and "this expression doesn't mean what you probably think it does" — all that suggests that some kinds expressions are more probable than others; ergo, those should be accommodated for at the expense of the unlikelier ones. So, the precedence levels and PEMDAS it is, instead of the abstractly-pure, from-the-first-principles, strictly left-to-right order which makes only its inventor, with a very peculiar kind of mind, happy at the expense of most of the actual programmers and users of the language.