On Wednesday 30 April 2014, 13:51:38, Rustom Mody wrote:
Without claiming to cover all cases, this is a 'principle' If we have: (⊞) :: a -> a -> b (⟐) :: b -> b -> c then ⊞'s precedence should be higher than ⟐. But what if (⟐) :: b -> b -> a?
This is what makes it natural to have the precedences of (+) (<) (&&) in decreasing order.
This is also why the bitwise operators in C have the wrong precedence: x & 0xF == 0xF has only 1 meaningful interpretation; C chooses the other! The error comes (probably) from treating & as close to the logical operators like && whereas in fact it is more kin to arithmetic operators like +.
That comes from `&` and `|` being logical operators in B. Quoth Dennis Ritchie (http://cm.bell-labs.com/who/dmr/chist.html in the section "Neonatal C"):
to make the conversion less painful, we decided to keep the precedence of the & operator the same relative to ==, and merely split the precedence of && slightly from &. Today, it seems that it would have been preferable to move the relative precedences of & and ==, and thereby simplify a common C idiom