Dennis Ritchie on the priorities of && || vs. == etc. (1982) | Hacker News Reader

Dennis Ritchie on the priorities of && || vs. == etc. (1982)

lysator.liu.se

168 pointsspc476171 comments

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.

Thank you for this additional context.

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:

  if ((a==(b & c))==d) ...

> 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.

Sure, you can use parentheses everywhere, but the code would be quite noisy. Do you think this:

  ((window.location).href) == foo;

is more readable than:

  window.location.href == foo;

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.

[0] https://news.ycombinator.com/item?id=38886613

[1] https://wiki.sei.cmu.edu/confluence/display/c/EXP00-C.+Use+p...

Why was it important to allow you to write:

    if (a==b & c==d)

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.

Because before there was && the & was used to mean the same as && does today. This happened when the context was Boolean such as an if.

I think at that point in C's development && and || did not exist: the bitwise were the only options.

To be fair, Dennis says:

>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

> && and || (which mimics & and |)

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.

But remember that * and + don't short-circuit. This won't work:

  found = (p != NULL) * (*p ! = 0);

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.

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

Pipe looks far too much like a 1 or lowercase ell.

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))
      ...)

Most, and possibly all languages I've used day to day do not have prefix operators like that.

Prefix operators considered harmful for readability.

... at the cost of having parentheses around every subexpression.

I hate Excel for this very reason.

Convert them to arithmetic. If you ignore the casting,

  a && b   is just   a * b
  a || b   is just   a + b

Now you remember the precedence between them (except in broken languages, of which the only notable one is shell).

Is there an intuition for this correspondence otherwise I don't think it's very helpful

a * b * c is only nonzero if all of a, b, c are nonzero. That's AND, and should be pretty intuitive.

a + b + c is nonzero if any of them are nonzero. (Remember each value is either 0 or 1.) So that's the intuition for OR.

a+b+c is nonzero if any of a or b or c are nonzero.

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.

Natural numbers are the natural numbers for me! (ISO 80000-2, of course)

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.

Conjunction used to be called logical product, and disjunction logical sum, for the reason the other commenters pointed out.

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 :)

"true is a #define for 1" is bad idea. Because when `x` is, say, `2` then `if x` is not the same as `if x==true`.

That's just the way C is. If you want to check "truthiness" (as much as you can in C), just do 'if x'.

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.

Then what is _Bool, if not a built in boolean type?

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.

_Bool isn't part of stdbool. It's a language keyword. C23 introduces full support for bool with true and false as keywords.

Kudos to the people that responded to explain why the correspondence is helpful.

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.

There is:

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.

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).

[0] https://en.wikipedia.org/wiki/Ring_(mathematics)

More than just a ring, it is the simplest finite field.

Saturation is actually the wrong way to think about bools when other operations get involved:

saturate(0 - 1) = 0

bool(0 - 1) = 1

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)).

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.

Yes, sometimes logical AND called logical multiplication and logical OR called logical summation.

It seems clear for me, because I remember learning De Morgan's Laws in electronics class and from one specific level of Turing Complete game.

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.

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...

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:

A * (B + C) = A*B + A*C

A + (B * C) = (A + B) * (A + C)

1+1 isn't zero, so it's one.

> 1+1=1?

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.

It’s true as long as you don’t chain more than a couple billion Boolean checks.

More importantly, only if you don’t rely on short circuiting logic.

I suspect that most people here won’t get the joke. Renault pulled out of the US market 40 years ago, and was never more than a tiny player.

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.)

Isn't it x ^ y which is like x + y?

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.

[1]: https://en.wikipedia.org/wiki/Boolean_ring#Relation_to_Boole...

xor is more like a substraction...

^ is like + when operating over bits, since (bit)2 == 0

| is like + when operating over bools, since (bool)2 == 1

Yeah. To sum two bits x and y, the immediate sum is x XOR y, and the carry is x AND y. That's how a simple half-adder circuit can be made.

0x8000 && 2 != 0x8000 * 2

-1 || 1 != -1 + 1

0x8000 || 0x8000 != 0x8000 + 0x8000

(with a 16-bit integer, adjust accordingly for larger word sizes)

> 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.

because 1 \and 0 = 0 same as 1 * 0 = 0 and 1 \or 0 = 1 same as 1 + 0 = 1

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.

  $ true; echo $?
  0
  $ false; echo $?
  1

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.

Actually if you think about Boolean logic as mod 2 arithmetics xor is addition, rather than or.

> except in broken languages, of which the only notable one is shell

The array language people (APL, J, K) are going to come in and protest, but you aren't going to be able to understand them.

Hey, even Dijkstra agrees with us on this one:

> 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.

https://www.cs.utexas.edu/users/EWD/ewd13xx/EWD1300.PDF (page 4-5)

Depends on the shell. Murex, for example, follows order of precedence correctly

No. Then I have to think about it.

I have (gently) jumped on peoples' cases for not using parentheses in expressions involving these operators, and will continue to do so, thanks.

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.

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.

And floating-point addition is not associative in any language:

    ((x**b) * a) + c

Is equivalent and is the clearer way to express it.

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.

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 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:

(isAdmin || (canReadDocument && canModifyMetadata)) && accountIsActive

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.

Just nitpicking: "a+b+c+d" in C is equivalent to "((a+b)+c)+d" not to "a+(b+(c+d))".

I otherwise agree with your comment: in most cases, unnecessary parentheses make the code slower to read, just like unnecessary "==true".

just a fun little anecdote.

I wrote a piece of code that said ` if ( boolean_variable == true)`

this was meant to be "if neither false nor null", since the variable was nullable (kotlin), until someone else tried to "fix the beginner mistake" :P

luckily kotlin requires you handle the nullability and the other person immediately figured out what was going on.

The other person was me, a couple of months down the line.

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.

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.

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]

[0] http://archive.adaic.com/standards/83rat/html/ratl-03-06.htm...

[1] https://tutorial.ponylang.io/expressions/ops#precedence

[2] https://github.com/ziglang/zig/issues/114

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.

The late arrival of a Free and Open Source compiler certainly didn't help its adoption in Free and Open Source circles.

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.

I see pi-e-sigma beat me to it, but:

C++ is at least as complicated as Ada, both in terms of using the language and in terms of writing a compiler for it.

C++ also sees plenty of use in military applications. The F-35's 141 page C++ coding standard is publicly available, for instance.

https://www.stroustrup.com/JSF-AV-rules.pdf

What about using the same associative operator multiple times?

A + B + C is permitted in Ada.

https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Devel...

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).

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.

You’re in good company[1]:

  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.

[1] https://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/E...

This article is a joy to read.

> 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.

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.

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.

|| is lower precedence than &&. I memorized that, just like I memorized that + is lower precedence than *.

There are some languages (e.g. shell) where they have the same precedence.

Prettier (JavaScript) adds parens like you suggest automatically.

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.

I'm always surprised when people don't know this one because they're like multiplication and clamped addition.

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 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.

Do you know the priority in this?

[ -e "${target}" ] && echo "Getting information about ${target}" && stat "${target}" || echo "Failed to stat file."

EDIT: What about the || die("...") pattern in Perl?

Or the fact that the glyphs in || are visually lower than the glyphs in &&?

Or that "and" comes before "or" in the expression "and/or"?

Shell scripting sucks, but that’s hardly news.

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.

The shell command is very readable.

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

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 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...

This is the best way in my opinion. Sacrifice a second of typing for clarity. I try to do this with expressions in general.

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.

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.

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.

[1]: https://www.w3.org/TR/WGSL/#operator-precedence-associativit...

Novel among mainstream languages, but not unseen before: https://blog.adamant-lang.org/2019/operator-precedence/

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.

> 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.

& vs && doesn't feel like a problem to me.

& 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.

Yes, the latter issue comes up when the user meant to say && but types & instead.

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.

Off the top of my head I can’t think of anything that should bind more weakly than the equivalence.

Really? Do you think equivalence should be weaker than && and || so that you would write

  if ((a==0) && (b==0))

instead of

  if (a==0 && b==0)

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.

> 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

Indeed, I forgot to specify unsigned.

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.

> match the traditional precedence in logical expressions

arithmetic expressions?

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.

Python also fixed it.

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.

[1] https://en.cppreference.com/w/cpp/language/operator_preceden...

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.

For languages that have strict distinction between booleans and integers (or other non-logical types) there is the natural priority of operations:

1) algebraic

2) relational

3) logical

From this, bitwise & and | are algebraic, so they should have higher priority than relationals.

One problem is !, which as a logical operator should have much lower priority.

Another problem is ==, which could be interpreted as both relational (when used on integers) or logical when used on booleans).

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.

Well in C-derived languages && and || will short-circuit the evaluation whereas & and | will not.

Aside, In Oral Tradition in Software Engineering by Bryan Cantrill, he talks a bit about the lack of logical xor in C. https://youtu.be/4PaWFYm0kEw?t=2236&si=MZPbopZPQtnnT-Tb

Forths often use -1 as TRUE so logical and bitwise operators coincide.

So did BASIC traditionally, with no short-circuiting behavior AFAIK. At least Visual Basic has `AndAlso` and `OrElse` variants that do short-circuit though.

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.

^ is a lot more valuable.

Pascal also uses the same operators for bitwise and logical and and or and they’re simply and and or.

I'm not familiar with Sail, but the reason for separate logical operators is that you want short-circuiting behavior. For example, in:

    (a != NULL) && a->x

You don't want to right-hand side to be evaluated if the left-hand side is false.

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.

It does short circuit if the parameters are booleans.

> After all, we had several hundred kilobytes of source code, and maybe 3 installations....

I don't know if the following addendum is apocryphal or not, but I still like it.

Follow-up question: several hundred kilobytes? Why didn't you just grep for all instances of "&"?

Dennis Ritchie: because that happened in 1972, and Ken would write grep only in 1973.

Several comments about && and ||. But where does == go?

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. In C and C++, == has a higher precedence than && and ||, so `A && B == C && D` parses as `A && (B == C) && D`.

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.

WTF? Seriously, just check any C/C++ reference, equality operator has higher precedence than any logical or bitwise one.

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.

On second read I C your point given the context. Got triggered because I feel hn is downhill lately. Cheers!

== is really just a logical xor anyway.

You mean "xnor", right? It's the != operator which corresponds to xor.

I did! Thanks.

man operator

this is why lisp is beautiful

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.

Reply on news.ycombinator.com