Make Eq type class single method

Tom Ellis tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk
Wed Oct 20 15:08:55 UTC 2021


On Wed, Oct 20, 2021 at 04:55:15PM +0200, Joachim Breitner wrote:
> Am Mittwoch, dem 20.10.2021 um 16:39 +0200 schrieb Joachim Breitner:
> > If no: would it be worth removing it?
> > 
> > Yes, every change is annoying, but if are going to keep using Haskell
> > the next 30 days, it may pay off? And it might not be too bad: Remove
> > it from base, but teach GHC to not error out if an instance defines
> > (/=), but print a warning and otherwise ignore it. Libraries can remove
> > it if it is defined, which is a backwards-compatible change.
> 
> And an (important?) benefit would be that now Eq would then be a
> single-method class, which are compiled by GHC more efficiently – they
> essentially _are_ the (==) function, not a tuple of both methods. For
> something as low-level as (==), this might be measurable…

Since (/=) is an Eq class method it can be implemented on (Int, Int)
as

  (x1, x2) /= (y1, y2) = (x1 /= y1) || (x2 /= y2)

If it were not a class method it would have to be implemented as,
after inlining

  (x1, x2) /= (y1, y2) = not ((x1 == y1) && (x2 == y2))

Might not the latter be less efficient, because of the extra `not`?

Tom


More information about the Libraries mailing list