Please note that, despite the misleading title, TFA is about the precedence of bitwise operators & and | with respect to the comparison operators (== and all the others). In particular it was asked to Ritchie why the former are weaker than the latter in C, a rule generally considered a mistake because it makes it impossible to write common expressions like
if (addr & mask == 0)
without adding extra parentheses:
if ((addr & mask) == 0)
TFA is not about the relative precedence between & and | (which is well understood, although disputed, and has mathematical basis), or between && and || (which mimics & and |). And TFA is not even about the precedence of the logical operators && and || vs. the comparison operators.
I'm writing this because I've seen a lot of comments that, while interesting in themselves, completely misunderstood the premise.
So in short, bitwise operators have lower precedence than comparisons to allow you to write:
if (a==b & c==d) ...
but of course, this means you can't write bitwise checks like this:
if (addr & mask == 0) ...
The problem could theoretically have been solved when the shortcut operators were introduced, by increasing the precedence of & and | to be higher than comparisons, but have the shortcut operators be lower. So you would be able to write both:
if (a==b && b==c) ...
if (addr & mask == 0) ...
But this was not done due to concerns of backward compatibility with existing code, since now every expression using the old pattern would subtly change semantics. E.g. the first example would now be parsed as:
> you could write [...] but of course, this means you can't write
I found this rather difficult to read. You could write those expressions. They're legal C code. Whether they will have the expected semantics will depend on, well, what you expected.
The more general problem is code that relies too heavily on precedence rules in the first place. Precedence-related bugs and readability issues are easily avoided, just use parentheses. As I mentioned in another comment in this thread, some languages force the programmer to do this.
I said code that relies too heavily on precedence rules. Your example doesn't do so.
In another comment [0] I mentioned that the Ada and Pony languages force the programmer to use parentheses when the expression would otherwise be confusingly reliant on precedence rules. Neither language requires unwieldy overuse of parentheses.
This C programming style advice article similarly recommends a middle-ground approach. [1]
I agree that unnecessary syntactic noise is bad (although this is essentially true by definition, as it's always a derogative). It can harm readability and make bugs more likely.
I always thought using the bitwise operator as if it were a logical operator was simply a mistake, even though it works because false is 0 and true is 1.
Edit: Mea culpa for reading and responding to the comments before the article.
I've always thought of it as mimicking * (multiplication) and + (addition), and you can actually use * and + in place of && and || if you wanted to (not advisable, though the idea can be used in expressions to produce branchless code, common technique in GPU shader code). I used to use this trick in TI99/4a BASIC which lacked "AND" and "OR" in "IF" statements, but because boolean expressions evaluated to integer 1 and 0 for true and false, multiplication and addition could serve as AND and OR.
>The priorities of && || vs. == etc. came about in the following way.
I think it takes some serious concentration to tease out that he is indeed trying to explain what you indicated. Either that, or my brain is just thoroughly cooked.
I'm not arguing with you -- I think you're absolutely right -- but man, Dennis made it hard on us here
I don't even know the priority between && and ||. If I'm using both, I use parentheses just so it's more explicit. "a && b || c" should flag a linter, IMO, with "(a && b) || c" or "a && (b || c)" being required.
> except in broken languages, of which the only notable one is shell
All binary messages in Smalltalk (messages with selectors consisting of punctuation, like !@+-, including punctuation sequences like "+-&|", if you want) have the same precedence, and the keyword variants (which short-circuit, using block arguments) and: and or: also have the same precedence (one level lower than the binary/punctuation messages), but because they take block arguments, are usually disambiguated:
a | (b & c) "parens needed to ensure b & c is evaluated first"
ifTrue: [self doSomething]
ifFalse: [
"because the and: is sent in a block arg to or:, it won't be evaluated unless or:'s receiver is false"
(self hasPendingTask or: [self updateTaskQueue and: [self hasPendingTask]])
ifTrue: [self processTask]]
Smalltalk is extremely elegant, powerful, and simple. 6 reserved words, 3 levels of operator precedence, and not much syntax to learn. It's what r5rs Scheme should have been.
> Smalltalk [...] what r5rs Scheme should have been.
I'm a fan of both languages, but R5RS Scheme was to be an algorithmic language, and Smalltalk is a particular flavor of OO language (class-instance, single dispatch).
Would you say that doing conditionals and Boolean expressions with Smalltalk's object semantics and `ifTrue:ifFalse:` and mix of `and:` and `&` etc. is cleaner than Scheme's `if`, `and`, etc. syntax?
> 3 levels of operator precedence,
Scheme doesn't see what's wrong with fewer:
(if (or a (and b c))
(do-something)
(if (or (has-pending-task)
(and (update-task-queue)
(has-pending-task)))
(process-task)))
By "should have been" I meant striking the balance of simplicity, power, and ease of learning that Smalltalk does. R5RS is simple and powerful (even more powerful due to macros), but not really usable, since it doesn't ship with something like Smalltalk's object model out-of-the box that streamlines creating ADTs and code reuse. Instead they give you the rudiments (functions, closures) and leave everything else up to you.
Yeah, the lack of a basic record/struct/object was felt quickly in R5RS. (Sure, you can whip up something atop vectors, or alists or other pair structures, or some arrangement of closures.)
SRFI-9 soon introduced a record type, and various Scheme implementations introduced much more.
Racket (nee MzScheme, or PLT Scheme) was one of them that introduced an object system, which was neat in some ways (e.g., mixins), but rougher in others, and thankfully it was limited to pedagogic and GUI use. There was also at least one CLOS-like. Later, Racket got a `struct` concept with some interesting hooks (e.g., inheritance/subtyping), and some simpler version of that might've been a good candidate for R5RS.
I'm don't know where RnRS is going recently, but I could imagine a fundamantal record/struct type, or interfaces more like the current Rust thinking.
Some interesting parallels between the original Scheme and message-passing from "The First Report on Scheme Revisited" by Sussman and Steele
> We were very pleased with this toy actor implementation and named it “Schemer” because we thought it might become another AI language in the tradition of Planner and Conniver. However, the ITS operating system had a 6-character limitation on file names and so the name was truncated to simply SCHEME and that name stuck. (Yes, the names “Planner” and “Conniver” also have more than six characters. Under ITS, their names were abbreviated to PLNR and CNVR. We can no longer remember why we chose SCHEME rather than SCHMR—maybe it just looked nicer.)
> then came a crucial discovery. Once we got the interpreter working correctly and had played with it for a while, writing small actors programs, we were astonished to discover that the program fragments in apply that implemented function application and actor invocation were identical! Further inspection of other parts of the interpreter, such as the code for creating functions and actors, confirmed this insight: the fact that functions were intended to return values and actors were not made no difference anywhere in their implementation. The difference lay purely in the primitives used in their bodies. If the underlying primitives all returned values, then the user could (and must) write functions that return values; if all primitives expected continuations, then the user could (and must) write actors. Our interpreter provided both kinds of primitives, so it was possible to mix the two styles, which was our original objective.
> But the lambda and alpha mechanisms were themselves absolutely identical. We concluded that actors and closures were effectively the same concept.
My problem here is that I distinguish between multiplication and addition by seeing which one distributes over the other.
a * (x + y) = (a * x) + (a * y)
However, the reverse doesn’t work…
a + (x * y) =? (a + x) * (a + y)
Why is this a problem?
a ∧ (x ∨ y) = (a ∧ x) ∨ (a ∧ y)
a ∨ (x ∧ y) = (a ∨ x) ∧ (a ∨ y)
Both are true. So, who are we to say that one corresponds to multiplication, and the other corresponds to addition? The two operations are too similar to each other.
Choosing false = 0 and true = 1 is putting the cart before the horse.
It is equally true that 1*0=0 is the same as false|true=true, and 0+1=1 is the same as true&false=false.
But it is also not true that 1+1=1, so it is probably wrong to equate 'or' with '+'. The operation has the wrong properties.
As someone who sometimes dabbles in electronics, 0 = true makes a lot of intuitive sense to me. You have your pin with an open collector, your pull-up resistor, and “true” (as in, it is true that the transistor is conducting) pulls the voltage to ground, which is 0.
As someone who uses a Unix shell, 0 = true makes a lot of intuitive sense to me.
You can interpret 0 and 1 as probabilities. 1 + 1 = 1 in this case makes sense because P(A or B) = P(A) + P(B) - P(A and B). You can interpret "A or B" as a set union and "A and B" as a set intersection. Of course it's easy to draw a three-way correspondence between Boolean arithmetic, the events represented by the empty set and the whole space, and sets within some universe because all the objects are so simple, but these correspondences also generalize well to systems with more than two possible values. The ease of generalizing makes me think it's not just a matter of coincidence or convention that we have 0 <=> false.
You've just moved the point where we make the arbitrary choice to here:
> You can interpret "A or B" as a set union and "A and B" as a set intersection.
{True, False, Or, And} and {False, True, And, Or} are two different naming conventions for the exact same structure: the unique boolean algebra on two elements.
A union B is defined as the set of things that are in A or in B; A intersect B is defined as the set of things that are in A and in B. So I don't really see it as an arbitrary choice.
Also if you forget which is multiplication and which is addition, remember false is 0 and true is 1, then work it out from there: a * b is only nonzero if both of them are nonzero, so it's AND.
Yeah, | is technically x + y + x*y over GF(2) (this is the Boolean ring to Boolean algebra relation [1]). The GP is still a good way to remember the precedence though.
The neutral element for + is 0 (x + 0 = x for any x).
The neutral element for * is 1 (x * 1 = x for any x).
Furthermore, you have arithmetic properties like x * 0 = 0 for any x (annulation) or (x + y) * z = (x * z) + (y * z) for any x, y, z (distributivity).
Similarly:
The neutral element for OR is false (x OR false = x for any x).
The neutral element for AND is true (x AND true = x for any x).
Furthermore, x AND false = false for any x, and (x OR y) AND z = (x AND z) OR (y AND z) for any x, y, z.
So OR works very much like + algebraically, and AND works very much like *.
When using 0 and 1 for false and true, AND is exactly the same as multiplication, and OR is like addition with saturation arithmetics (i.e. 1 + 1 = 1).
The common precedence rules stem from those parallels.
There's also a connection to probability: if you want the probability of A and B and C happening and they're independent, it's P(A) * P(B) * P(C). If you want the probability of A or B or C happening and they're mutually exclusive, it's P(A) + P(B) + P(C).
Similar analogue for set theory, as another commenter pointed out.
I've never heard of saturation arithmetic and now it all makes sense. Otherwise I thought it was more common to think of XOR as boolean addition, and OR would be represented as xy + x + y.
Yes, true and false with AND and XOR form a mathematical ring [0]. Still, OR is also an additive operation. IMO one could give OR and XOR the same precedence.
On the other hand, there is no strict need to have a dedicated boolean XOR operator, as it works the same as = (equals).
Fun (but not particularly useful fact) is you can also represent x OR y as 1 - (1 - x)(1 - y). This shouldn't be too weird since x OR y is equal to NOT ((NOT x) AND (NOT y)).
I always remember it in terms of set operations. && corresponds to set intersection, while || corresponds to set union. The union operation is similar to "adding" two sets together. You also have the distributive property: a && (b || c) == (a && b) || (a && c).
The analogy isn't perfect, because || is also distributive over &&, but addition isn't distributive over multiplication. I think this is actually one of the essential properties that distinguishes a Boolean algebra from a ring. Someone with more knowledge of abstract algebra could probably provide more insight here, though.
Yeah I just added that. I was hesitant initially cause you have to also note they're nonnegative, and that you're treating them like real numbers rather than mod 2.
IMO the intuition is to not use any intuition at all: there aren't built-in booleans in C, true is a #define for 1 and false is a #define for 0. For C conditionals, 0 = false, nonzero = true. So
a+b != 0 <=> a!=0 or b!=0
a*b != 0 <=> a!=0 and b!=0
Of course this intuition also reveals the pitfall behind this correspondence! You'd better make sure those are unsigned ints or #defined booleans, so you're not using general C expressions. 1 || -1 is true but 1 + (-1) is false.
Edit: forgot to mention: INT_MAX || 1 is true, but what about INT_MAX + 1 :)
I genuinely forgot stdbool.h existed, I don't actually write that much C myself.
My point was more around the conditionals being weakly typed around unsigned ints rather than a specific lack of built-ins. A lot of commenters were going into arithmetic mod 2 or philosophical issues, neither of which actually apply here.
Something nice in C is that "if (x)" is always equivalent to "if (x != 0)". NULL is a macro for 0, and so is false. Boolean expressions evaluate to 0 if they don't hold. This isn't true in C++, though.
this is the notation used in the chapters about boolean algebra in my digital design course. I think it's pretty neat. I honestly never looked into operator precedence in any language enough to notice the relation.
> I remember how much more pleasant the predicate calculus became to work with after we had decided to give con- and disjunction the same binding power and thus to consider p ∧ q ∨ r an ill-formed formula.
1+1=1? My maths education was a long time ago, but I triple checked with my calculator, and I'm uncertain this is quite right.
My own mnemonic: SAXO. Shift, And, Xor, Or. (Like a real Saxo, it's fun to go a bit faster like this, but you do have to trust everybody involved, because any accident is probably going to end up badly for you.)
And now you know the bitwise precedence as well! And this ordering actually works out tidily for common operations: "x=a<<sa|b<<sb|c<<sb"; "x=p>>n&m"; "x=x&~ma|a<<sa"; and so on. You do need brackets sometimes, but fewer than you'd think, and it helps the unusual cases stand out.
(Main annoying thing: a lot of compilers, even popular ones such as clang and gcc, don't actually seem to know what the precedence rules actually are, and generate warnings asking you to clarify. Presumably the authors didn't realise that C has an ISO standard, that can be consulted to answer this question? Very surprising.)
> (Main annoying thing: a lot of compilers, even popular ones such as clang and gcc, don't actually seem to know what the precedence rules actually are, and generate warnings asking you to clarify. Presumably the authors didn't realise that C has an ISO standard, that can be consulted to answer this question? Very surprising.)
The compilers do know what the precedence rules are, but they know that programmers don't routinely consult the ISO standard, so they emit those warnings to reduce the chance of error. Compilers are tools that are designed to help programmers avoid bugs. If they don't help programmers, they aren't doing their job.
Alternatively, they're encouraging programmers to be stupid and ignorant, causing a dumbing-down feedback loop which is ultimately damaging in the long term.
It ain't no surprise if you see the crap that passes for software these days and the nosedive in quality, but that's a rant for some other time...
True + True = True, because "true" means "not zero" and "false" means "zero". In most all languages that permit int->bool casting, if(2) will evaluate to "true".
The warnings clang and FCC generate are a style warning because it's unclear on casual reading. Even readers who know the precedence rules will typically want to insert the parentheses manually. If the meaning were undefined, the compiler would give an error, not a warning.
The analogy between logical AND and multiplication, and logical OR and addition is called Boolean Algebra, and it's very well known.
The analogy is that when you set 1 to true and 0 to false, 1 becomes the identity for AND, and 0 becomes the identity for OR. Just as 1 is the identity for multiplication and 0 is the identity for addition.
X * 0 = 0 | X ^ F = F
X * 1 = X | X ^ T = X
X + 0 = X | X V F = X
X + 1 = ? | X V T = T <-- This one breaks the analogy
With this, you can turn any logical expression into something that looks and feels like normal algebra, with the only weird exception being that both operators distribute over each other:
Better than that: the Saxo was from Citroen, who apparently haven't served North America since 1974 ;) The Renault equivalent would probably be the Clio.
(Not a big hot hatch connoisseur though, I must admit - I just remember the Saxo in particular as having a reputation of hitting a bad spot on the tradeoff graph for flimsiness/power/good sense of average member of target demographic.)
The Ada language requires explicit parentheses in the case of a succession of different logical operators precisely to avoid precedence-related bugs. [0]
In the Pony language, any expression where more than one infix operator is used must use parentheses to remove the ambiguity. [1]
The Zig language considered following Pony, but didn't. [2]
Ada is such an underrated language. The lack of its adoption is a testament to the old adage that technologies don't thrive or die on their technical merits.
I remember reading a discussion on it in a year around <= 2000 and it was a general consensus that Ada’s printed standard is too heavy to move around, let alone implement. Military/corporate-ish affinity didn’t help either.
Compare C++ and Ada. C++ standard is an order of magnitude bigger and more complex and yet C++ is thriving. So Ada's failure definitively is not due to the language complexity. C++ has been supported heavily by the corporate, too. Biggest C++ champion was Microsoft, after all.
If I read this right, Zig follows Pony partially. The very basic stuff like addition and multiplication follows the well known precedence rules („chainable“), but eg bitwise operators whose precedence nobody can remember must be put into parentheses.
I find this a good compromise between being explicit and readability (Lisp syndrome).
Do not introduce priority rules that destroy symmetry. I remember how much more pleasant the predicate calculus became to work with after we had decided to give con- and disjunction the same binding power and thus to consider p ∧ q ∨ r an ill-formed formula.
> We don’t want to baffle or puzzle our readers, in particular it should be clear what has to be done to check our argument and it should be possible to do so without pencil and paper. This dictates small, explicit steps.
I feel this justifies why I sometimes write code with lots of temporary variables on their own lines: It's a way to break down the problem, to name each thing (especially when it's not a simple method-call to a correctly-named method) and it also makes it easier to verify the behavior with the average line-by-line debugger or line-by-line debugging easier.
In many cases, such temporary local variables have no negative performance impact, being optimized away.
It should be noted that this is not same to using a default order (typically, but not necessarily, left-to-right) in such case. Some languages use a term "non-associative" instead.
I know the priorities of these, but I still use parentheses to make the precedence explicit. I think it's just great practice -- and it makes things easier for the next dev who might have to work with the code.
Consider (&& a b) and (|| a b) for no uncertainty over operator precedence and easy variadic representation (&& a b c) at the cost of zero additional parentheses.
While true and might be easy to read in the example context of a b c I'd imagine having the && separator in real world conditions to be far more readable and clear for vast majority if people
I actually think the variadic logical and is more readable, and wish more languages had it. As long as all the arguments are lined up vertically, you can think of it as a sequence of tests for true that exits at the first failure. It's more obvious with the variadic operator. Contrived comparison:
if (a != null && x != 0 && a.use_it(x))
{
...
}
(if (and (not (null a))
(/= 0 x)
(use-it a x))
...)
It bothered me a while for "short" boolean expressions to have a linter expect parens, where I'd simultaneously expect everyone with a high school degree to understand the implicit operator precedence.
Then, since my first bug having been merged that was caused by a && vs || operator precedence mistake, I like my parens-always ESLint rule (or whatever exactly it was called).
Even redundant parens can start to look as pleasent as indents, after getting used to them.
In short, I think expressions like (a && b || c && d || e) are a footgun and linters should forbid them. Parens fit well with logical thinking, similar to relative clauses in language.
Sorry, but I'm of the exact opposite opinion. If you don't know, learn. It's not hard (as other sibling comments have noted). Code with superfluous parentheses is even more confusing, since I expect them to be present only when overriding precedence.
...and I just realised your username adds some additional irony.
Explicit is better than implicit. I think the real problem is not breaking up complicated expressions. If it's more than just a few pairs of parentheses making it hard to read there's something more wrong there.
I think most people agree "a*x**b + c" is more clear than "(a*(x**b))+c".
Or "a+b+c+d" is more clear than "a+(b+(c+d))".
Why are we happy to avoid parentheses for these operations but not for && and ||? Probably because we are all really used to the precedences for + and *.
So at the end of the day, what's more clear depends on How familiar the engineers working on your code are with a given set of operators.
Parentheses need to be matched. That adds cognitive overhead. It's especially frustrating when you find the closing parenthesis and then realise it wasn't even necessary.
IMHO it's on a similar level as "== true" "== false" and variations thereof --- absolutely redundant and unnecessary, and shows a lack of knowledge. The same "explicit is better than implicit" mantra is often repeated to justify the latter, but if you think
if(x == true)
is somehow more "explicit", then surely
if((x == true) == true)
is even better?
So at the end of the day, what's more clear depends on How familiar the engineers working on your code are with a given set of operators
If someone is not familiar then they should be encouraged to learn and level up, rather than pulling down everyone else.
I got little scars from knowing precedences and then switching languages. I also got them from short-testing booleans that later turned into T|boolean. And all these clean just_p’s incrementally evolved into !just_p ? !un_q : t’s. Because I was flying through a mass-change after a day and had no mental capacity to repack the meaning of the previous expression and retain the context of a changeset.
Crystallized syntax is clear, but also extremely fragile, if you take humans into account. We have limits. Everything pushes us to these limits. Any complexity spike that overlaps with secondary complexity or fatigue is above our limits. That’s where we make mistakes.
The big difference between adding the first `== true` to `if (x)` and adding more is that for a bare `x` you need more context to know whether the expression inside the `if` is of boolean type or something that will implicitly be casted to boolean. With `x == true` you know just looking at the `if` statement that it is a boolean expression. Adding more `== true` does not make it more explicit.
If the purpose of quirky code isn't immediately clear from the context (and if the code can't easily be reworked to make it cleaner), it's a good candidate for commenting.
Most people might agree with that, I don't know, but I know I don't think your first example is clearer. And I've had the operator precedence rules memorized for decades. Parentheses save my brain a step.
The second example is irrelevant because addition is commutative so the parentheses are meaningless. (This is why languages shouldn't override + to be a concatenation operator.)
The important part that makes the parens in the second operation unnecessary is that addition is associative, not that it's commutative. And concatentation is also associative, so even if those were strings, the parens would still be unnecessary.
That is, (a+b)+c == a+(b+c).
Interestingly, C integer addition is not actually associative, since (1+INT_MAX) + (-1) is UB, but 1+(INT_MAX+(-1)) should in principle be defined as INT_MAX.
I think the opposite, I think most people would prefer the version with parentheses, including myself, also, in 20 years experience all companies I’ve worked for would prefer the second expression.
The first expression looks messy and confusing, the second is completely clear in how it will work.
If you drag it out of context, sure the first example looks more clear. But there is a difference between Boolean logic and arithmetic, and as soon as you use proper variable names, that becomes evident:
Using parentheses makes the code a lot easier to understand here. All these variables carry state with lots of subtleties. Figuring out the implications of all the different cases becomes a lot easier when the code clearly tells them apart.
Although I agree, most times where I mix any of these without parentheses I end up having to explain it either in code review or when somebody does a `git blame` a couple months later. Rather than waste everyone's time explaining it, it's easier to just use the parentheses since it's what many/most people expect and everyone else can read it well enough.
Agreed, it's quite justified: If their implicit combined behavior isn't easy-to-read-obvious to the author composing the code, then it's also problematic for any poor future-person (perhaps even the original author) tasked with reading and verifying the code. Checking parens is faster than remembering and applying the knowledge.
Plus the rules may be just different enough in different languages to trip up even those who try to remember them.
I once implemented a logical expression evaluator to be used as filters on a search page. My boss tested it and filed a bug because he expected OR to have higher precedence than AND. I pointed him to a page with the rules and told him that he could use parenthesis if he wanted to modify the order of precedence. He was sort of convinced but never closed the ticket. Every release he would move it to the next release.
I just asked myself the question for SQL's AND and OR this week. Apparently AND takes precedence but I don't know if it is consistent accross all SQL engines. In any case it seems to me that few programers will know anyway, so it is bad practice to not have parenthesis.
I also do (it also makes it more clearly, in my opinion), as well as with the bitwise operators & and | but sometimes with the bitwise operators the code is written in such a way that the precedence doesn't matter anyways and so I will not need to add parentheses anyways.
I do the same, not because I don't know the priorities, but because in my 35+ years career, I've seen so many times when cut+paste of partial expression leads to disaster just because it wasn't grouped properly with parenthesis..
Early in my career I erased several megabytes of shared memory on a mini computer, ie DOZENS of users worth of memory just because I was being 'clever' and cut+pasted bits of an expression the wrong way.
Since then, as a rule, sod the priorities, parenthesis it is...
If I really have to touch a bash script, I just assume nothing works like I might expect from proper programming languages despite any surface similarity, and google every construct with sweat drops dripping down my face. ChatGPT has made the process somewhat more tolerable.
a && b && c is a common idiom for "stop if any step fails". In the shell language && and || are more like control flow concepts, rather than binary operators.
And a && b || c is a universal "ternary operator" (with one minor deviation) idiom across many languages, not just the shell
Smalltalk doesn't have operator precedence rules. They just apply left-to-right. The infix operators aren't part of the language - they're messages (aka methods), and precedence would be inconsistent with the language's simple syntax.
One of the most intriguing novel ideas in Carbon (One of the "C++ Replacement languages" announced in 2022) is the idea that operator precedence should not be a total order.
Lots of prior languages have tried either:
1. No operator precedence, expressions must use parentheses so that it's very clear
2. No operator precedence, everything just happens left to right regardless
But Carbon says what if we do have precedence, but only between operators which programmers expect to have precedence - whenever it's unclear what should happen the compiler instead rejects that, the same way many languages won't let you ask whether 5 == "Five" because you need to explain WTF you intended as most likely you've screwed up and didn't realise they're completely different types.
WGSL (the shading language for WebGPU) has something similar[1].
For example, `a + b << c` will fail to parse in a conforming implementation, as will `a << b << c` and `a && b || c`. Note however that `a && b && c` does parse. I find these rules to be well-thought through.
SmallTalk has the left-to-right for everything principle because everything is message passing and "operators" are just binary (as in two argument) messages which catches many out.
2 - 1 * 5
will return 5, while many would expect -3. You must apply parentheses if you want a precedence other than ltr.
The relative priorities of && vs ||, or & vs |, match the traditional precedence in logical expressions: "and" binds more tightly than "or", just as * binds more tightly than + ("and" is equivalent to * for one-bit values, and "or" is addition modulo 2). So I think that they got this correct.
However, the precedence of & vs &&, or & vs ||, etc is a source of problems.
& vs == is the real problem: `(val & MASK) == CONSTANT` needs parentheses due to this mistake.
`a & (b == c)` essentially almost never makes sense (== gives you a boolean, and when dealing with booleans you can use && instead), yet that it what you get by default if omitting the parentheses.
The example given in the post is that & used to be the only conjunction operator, before && was added. Therefore, it was normal to write “if (a==b & c==d)”. While this is definitely not used anymore, the historical context is useful for explaining why the precedence of & is so low.
I think equivalence and equality should different operators. 2==x should be a syntax error, because equivalence compares Boolean expressions (and possibly their extensions depending on the language). Equality should be checked with the customary sign, and assignment should be some visually asymmetric operator like :=. As you say, Equality should bind more strongly than the Boolean typed operations, including conjunction, disjunction, and equivalence.
Tangentially, I wonder if
if (a+b == 0)
generates more efficient code in presently popular languages with that syntax.
Sorry, I can't follow your reasoning. Probably I'm missing some basic vocabulary, because I don't appreciate the difference between equivalence and equality. Are we still talking about comparison operators?
I think GP is calling for == to only compare boolean values ("equivalence"), = to be necessary for comparing any other values ("equality"), and := to be used for assignment. Though I don't see the purpose in that, given that two boolean values are equal if and only if they are equivalent.
Unless "equivalence" is supposed to be useful for comparing boolean expressions with unbound variables? But evaluating that would require a built-in SAT solver, to be remotely performant.
Also, just because two integers sum to 0 doesn't mean they're both equal to 0, so replacing (x == 0 && y == 0) with (x + y == 0) wouldn't be valid. Regardless, it wouldn't make for more performant code: compilers already translate (x == 0 && y == 0) into the assembly equivalent of ((x | y) == 0) automatically, without the programmer having to mess with their code.
That still wouldn't be valid, since either unsigned integers wrap around on addition (the default behavior of most languages), in which case nonzero values can still sum to 0; or unsigned integer overflow raises an error, in which case the transformation is dangerous unless the integers are both strictly bounded in magnitude.
Unless the integers were unsigned big-integers, in which case performing the long addition with carries would take Θ(n) time, as opposed to the simple Θ(1) operation of just checking both their bit-lengths.
> However, the precedence of & vs &&, or & vs ||, etc is a source of problems.
Do you have any examples of this? In my experience you almost always want the bitwise operators to have a higher precedence than the logical operators, as using the result of logical operators as a bitmask makes little sense. Consider e.g. `A & B && C & D`, which currently is equivalent to `(A & B) && (C & D)`, but with reversed precedence would be equivalent to the almost nonsensical `A & (B && C) & D`.
Now, the precedence of == with respect to & and | is actually problematic (as Ritchie admits as well). Having `A == B | C` interpreted as `(A == B) | C` is almost never desirable. For extra annoyance, the shift operators do have higher precedence than comparison, so `A == B << C` does what you usually want (`A == (B << C)`).
It usually comes up if the user intended to write && and writes & at one point in an expression, the different precedence can produce an unexpected result. But gcc and clang have warnings for that.
The only operators with precedence between & and && are ^ and |, though. In e.g. the expression from the sibling comment, `a & b == c`, writing & or && doesn't make any difference (aside from short-circuiting). I guess it's an issue if you write & instead of && in an expression that also involves a bitwise-OR (or | instead of || in an expression that also involves logical-AND), but that seems quite rare. I expect that reversing the precedence of the bitwise and logical operators would create problems a lot more often.
Unfortunately even though this was called out as a mistake in 1982, much more modern languages (e.g. C#) are still copying it.
As painful as breaking changes might be, they beat the alternative of dealing with a bad design indefinitely. At least in more modern languages, the type checker usually catches the mistakes caused by this design mistake.
> much more modern languages (e.g. C#) are still copying it
Fortunately Go, Rust, and Swift all chose to defy C and fix the precedence of &, which I expect sets enough of a precedence (heh) for every language for the rest of human history to get it right.
Somewhere, I sat down and wrote a combined precedence table across many languages. It was quite hairy; sometimes there's even variation across language versions.
Besides `not` (which often has different precedence depending on whether it's a keyword or a punctuator, and is a great reminder that multiple levels of pratt parsing is meaningful), `await` is the one with the most variation - in most languages, it binds tighter than binary operators, whereas in C++ it's just barely tighter than assignment.
> `await` is the one with the most variation [..] in C++ it's just barely tighter than assignment.
That doesn't seem right to me. According to cppreference[1] it's the operator with the third-highest precedence, well above assignment, which is the second-lowest.
Hm, I looked at Wikipedia, and I'm pretty sure cppreference used to agree with it? Did it ever differ between drafts?
I've gotten surprisingly out of touch with the C++ world, even though it was my first serious language and I used to have the draft numbers memorized ...
quite interesting. in VHDL we have a similar thing. `<=` is the assignment operator, however after an if, it means "less than or equal". I'll have to check it this was inherited from Ada.
Edit:
on a quick glance, Ada uses the := as the assignment operator. However there seems to be only one version of the and, or, xor operators, used for both logical and bitwise.
There's a niche language called Sail that has & and | act as both bitwise and boolean operators. It actually works really well and isn't confusing at all after the initial "this is different". There's no real downside because it is a modern strictly typed language unlike C.
On the other hand I don't know if there's a real upside either. It's not very difficult to use && and || and it serves as extra documentation, and everyone is used to it by now.
I'm also not familiar with Sail, but you could have a single token ("&&") behave as either a bitwise or logical AND, depending on the context: if both operands are an boolean, operate logically, if both operands are an integer, operate bitwise. The complexity lies in what you do with mixed expressions. One solution is to just forbid them. This makes bitwise expressions nested within logical expressions more verbose (you'd need to add a cast), but I'd wager that those aren't used often in most high-level languages.
Most langages with a passing link to C support & and | on booleans (even when they have a legitimate non-integer boolean type). However they are eager which makes them generally useless.
So did BASIC traditionally, with no short-circuiting behavior AFAIK. At least Visual Basic has `AndAlso` and `OrElse` variants that do short-circuit though.
Lower than either, so you can do logical (or arithmetical) expressions on both sides of ==. Has nothing to do with nature, it's all about pragmatic decisions on how we want it.
Wrong? Did'nt ask how C does it and clearly you did not understand my simple comment. Wtf is going on with hn? It's turning into yet another site were kids think they seem smart by intentionally misinterpreting and bickering.
I interpreted GP's comment as asking what the precedence of == was (assumably in C, given that we're discussing a post by Dennis Ritchie). On second read it could also be interpreted as asking what a good precedence for == would be, in which case you're absolutely right. Sorry about that.
Indeed. But lisp is much more than prefix notation.
Different notations like revers polish notation also easier to parse. You can evaluate RPN only using stack.
Also, recently I learned about thread-last macro in emacs lisp. Using it you can evaluate forms from left to right, and using it you can write less parenthesis.
I'm writing this because I've seen a lot of comments that, while interesting in themselves, completely misunderstood the premise.