The definition of Ord
itself in the standard prelude requires there already be an Eq
instance:
class (Eq a) => Ord a where
...
So it would be just as wrong to violate
x == y = compare x y == EQ
x /= y = compare x y /= EQ
As it would be to violate (from the default definitions for these operators in Ord).
x <= y = compare x y /= GT
x < y = compare x y == LT
x >= y = compare x y /= LT
x > y = compare x y == GT
Edit: Use in libraries
I would be quite surprised if standard libraries didn't make use of Ord
's ==
and /=
operators. The specific purpose operators (==
, /=
, <=
, <
, >=
, >
) are frequently more convenient than compare
, so I'd expect to see them used in code for map
s or filter
s.
You can see ==
being used in guards on keys in Data.Map
in fromAscListWithKey. This specific function only calls out for the Eq
class, but if the key is also an Ord
instance, Ord
's compare
will be used for other functions of the resulting Map
, which is an assumption that Eq
's ==
is the same as Ord
's compare
and testing for EQ
.
As a library programmer, I wouldn't be surprised if any of the special purpose operators outperformed compare
for the specific purpose. After all, that's why they are part of the Eq
and Ord
classes instead of being defined as polymorphic for all Eq
or Ord
instances. I might make a point of using them even when compare
is more convenient. If I did, I'd probably define something like:
compareOp :: (Ord a) => Ordering -> Bool -> a -> a -> Bool
compareOp EQ True = (==)
compareOp EQ False = (/=)
compareOp LT True = (<)
compareOp LT False = (>=)
compareOp GT True = (>)
compareOp GT False = (<=)