[HN Gopher] Dennis Ritchie on the priorities of && || vs. == etc...
       ___________________________________________________________________
        
       Dennis Ritchie on the priorities of && || vs. == etc. (1982)
        
       Author : spc476
       Score  : 33 points
       Date   : 2024-01-05 22:01 UTC (58 minutes ago)
        
 (HTM) web link (www.lysator.liu.se)
 (TXT) w3m dump (www.lysator.liu.se)
        
       | Sohcahtoa82 wrote:
       | 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.
        
         | JonChesterfield wrote:
         | 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.
        
           | namrog84 wrote:
           | 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
        
           | NegativeLatency wrote:
           | Most, and possibly all languages I've used day to day do not
           | have prefix operators like that.
        
         | o11c wrote:
         | 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).
        
           | dananabread wrote:
           | Is there an intuition for this correspondence otherwise I
           | don't think it's very helpful
        
             | dataflow wrote:
             | 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.
        
               | explaininjs wrote:
               | a+b+c is nonzero if any of a or b or c are nonzero.
        
               | dataflow wrote:
               | 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.
        
             | naitgacem wrote:
             | 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.
        
             | aragonite wrote:
             | Conjunction used to be called logical product, and
             | disjunction logical sum, for the reason the other
             | commenters pointed out.
        
           | dataflow wrote:
           | 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.
        
           | tom_ wrote:
           | 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.)
        
             | pcwalton wrote:
             | > (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.
        
           | threatofrain wrote:
           | Isn't it x ^ y which is like x + y? Or is a bit more like the
           | xy + x + y.
        
       | o11c wrote:
       | 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.
        
       | naitgacem wrote:
       | 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.
        
       | not2b wrote:
       | 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.
        
       | IshKebab wrote:
       | 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.
        
         | secondcoming wrote:
         | Well in C-derived languages && and || will short-circuit the
         | evaluation whereas & and | will not.
        
         | 48864w6ui wrote:
         | Forths often use -1 as TRUE so logical and bitwise operators
         | coincide.
        
       ___________________________________________________________________
       (page generated 2024-01-05 23:00 UTC)