Precedence of plus and bit-wise-and
I was surprised today to find that C and Haskell differ on the precedence of addition and bit-wise and. In Haskell, bit-wise-and (.&.) binds tighter. In C, it's the other way around. While I like Haskell's precedence better, this was a gotcha; and I wondered if this behavior is documented somewhere. I looked through the Haskell wiki, but couldn't find anything pertinent. Discrepancies are always problematic. Without bike-shedding a lot, does anyone know if this was a conscious decision or merely a more natural one to take? Cheers, -Levent.
On Tue, Aug 15, 2017 at 8:07 PM, Levent Erkok
While I like Haskell's precedence better, this was a gotcha; and I wondered if this behavior is documented somewhere. I looked through the Haskell wiki, but couldn't find anything pertinent.
Documented in the Language Report, just as C's precedence is documented in the ANSI C standard (and, before that, the Language Report in the back of K&R). https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-820061 -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
I wasn't involve in the decision but personally I would expect "&" (and) to
have precedence like "*" and "|" (or) to have precedence like "+", whether
bitwise or logical.
It seems from what you're saying that's how Haskell works. Flipping it
would be more of a gotcha to me.
On Wed, 16 Aug 2017 at 10:08 am, Levent Erkok
I was surprised today to find that C and Haskell differ on the precedence of addition and bit-wise and.
In Haskell, bit-wise-and (.&.) binds tighter. In C, it's the other way around.
While I like Haskell's precedence better, this was a gotcha; and I wondered if this behavior is documented somewhere. I looked through the Haskell wiki, but couldn't find anything pertinent.
Discrepancies are always problematic. Without bike-shedding a lot, does anyone know if this was a conscious decision or merely a more natural one to take?
Cheers,
-Levent. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
On Tue, Aug 15, 2017 at 10:06 PM, Clinton Mead
I wasn't involve in the decision but personally I would expect "&" (and) to have precedence like "*" and "|" (or) to have precedence like "+", whether bitwise or logical.
It seems from what you're saying that's how Haskell works. Flipping it would be more of a gotcha to me.
C's precedence for bitwise ops is an infamous gotcha. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
On 16/08/17 12:07 PM, Levent Erkok wrote:
I was surprised today to find that C and Haskell differ on the precedence of addition and bit-wise and.
In Haskell, bit-wise-and (.&.) binds tighter. In C, it's the other way around.
It is worth noting that Haskell uses a different symbol (.&.) than C (&), so it's not altogether surprising. There is no generally accepted convention. In Erlang, bitwise and has the same precedence as * and bitwise or has the same precedence as + . In Standard ML, andb and orb are not operators at all. In Fortran, iand and ior are not operators at all. The & and | operators in PL/I are wider scope than the arithmetic and comparison operators, but they do double duty for bitwise operations and conditional operations, just as BCPL did. In Prolog, bitwise and and or have the same precedence as as + and thus as each other. In Ada, 'and' and 'or' have the same precedence as each other, wider scope than comparisons, and the language does not allow you to mix 'and' and 'or' without parentheses. In Pascal, the bitwise operators are actually called * and +. In Smalltalk, "bitAnd:" and "bitOr:" have the same precedence as each other, wider scope than "+" and "*" (which have the same precedence as all binary selectors). Not that Smalltalk technically _has_ operator precedence... SETL2 doesn't appear to have bitwise operations at all. I could go on, but I think I've made the point that expecting everything to be just like C is rather risky. For that matter, common advice for C programmers is "never mix arithmetic and bitwise operators without parentheses".
While I like Haskell's precedence better, this was a gotcha; and I wondered if this behavior is documented somewhere. I looked through the Haskell wiki, but couldn't find anything pertinent.
Discrepancies are always problematic.
The only language in which you will not find discrepancies with C is C itself, and I'm afraid you will find (semantic) discrepancies there. If I went around complaining that C doesn't look enough like APL, what good would that do me?
participants (4)
-
Brandon Allbery -
Clinton Mead -
Levent Erkok -
Richard A. O'Keefe