Precedence of plus and bit-wise-and

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Precedence of plus and bit-wise-and

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.
Reply | Threaded
Open this post in threaded view
|

Re: Precedence of plus and bit-wise-and

Brandon Allbery
On Tue, Aug 15, 2017 at 8:07 PM, Levent Erkok <[hidden email]> wrote:
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).


--
brandon s allbery kf8nh                               sine nomine associates
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Precedence of plus and bit-wise-and

Clinton Mead
In reply to this post by Levent Erkok
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 <[hidden email]> 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.

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.

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Precedence of plus and bit-wise-and

Brandon Allbery
On Tue, Aug 15, 2017 at 10:06 PM, Clinton Mead <[hidden email]> wrote:
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
[hidden email]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Precedence of plus and bit-wise-and

Richard A. O'Keefe
In reply to this post by Levent Erkok


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?

_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Precedence of plus and bit-wise-and

Doug McIlroy
In reply to this post by Levent Erkok
The reason for the low precedence of & and | in PL/I and C is
that those were used as Boolean operators in conditions. For
example
        lessequal(a,b) { return(a<b | a==b); }
_______________________________________________
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.
Reply | Threaded
Open this post in threaded view
|

Re: Precedence of plus and bit-wise-and

Doug McIlroy
In reply to this post by Levent Erkok
Sorry for hitting return prematurely. The final sentence below
tells the tale.
The reason for the low precedence of & and | in PL/I and C is
that those were used as Boolean operators in conditions. For
example
        lessequal(a,b) { return(a<b | a==b); }
That usage was baked in before the short-cut operators && and ||
were introduced in C.

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