Re: Make Eq type class single method

Tom Ellis <[email protected]> Wed, 20 Oct 2021 16:08:55 +0100
Newsgroups gmane.comp.lang.haskell.libraries
Message-ID <20211020150855.GQ22523@cloudinit-builder>
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
_______________________________________________
Libraries mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries