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