On Wed, Oct 20, 2021 at 04:39:21PM +0200, Joachim Breitner wrote:
I am revisiting some educational material about Haskell, and I stumble over something that I keep stumbling over. I thought there was prior discussion, but I couldn’t find it (operators hard hard to google for).
Why does Eq have a (/=) method?
For primitive types CPUs often have both '==' and '/=' instructions, and so a direct call to `(/=)` may be more efficient than calling `(not .) . (==)`. The base package defines: instance Eq Int8 where (==) = eqInt8 (/=) = neInt8 instance Eq Int16 where (==) = eqInt16 (/=) = neInt16 instance Eq Int32 where (==) = eqInt32 (/=) = neInt32 instance Eq Int64 where (==) = eqInt64 (/=) = neInt64 instance Eq Word8 where (==) = eqWord8 (/=) = neWord8 instance Eq Word16 where (==) = eqWord16 (/=) = neWord16 instance Eq Word32 where (==) = eqWord32 (/=) = neWord32 instance Eq Word64 where (==) = eqWord64 (/=) = neWord64 There are also various cases involving equality/inequaility on getUnique, ... compiler/GHC/Core/Coercion/Axiom.hs:instance Eq (CoAxiom br) where compiler/GHC/Core/Coercion/Axiom.hs- a == b = getUnique a == getUnique b compiler/GHC/Core/Coercion/Axiom.hs- a /= b = getUnique a /= getUnique b compiler/GHC/Core/Class.hs:instance Eq Class where compiler/GHC/Core/Class.hs- c1 == c2 = classKey c1 == classKey c2 compiler/GHC/Core/Class.hs- c1 /= c2 = classKey c1 /= classKey c2 I don't know whether optimisations to use direct CPU instructions pay their way relative to the cost of larger Eq dictionaries in other contexts, but this seems to be at least a plausible reason. -- Viktor.