Re: Make Eq type class single method

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.
_______________________________________________
Libraries mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries