Re: Make Eq type class single method
Jens Blanck <[email protected]> Wed, 20 Oct 2021 16:05:04 +0100
| Newsgroups | gmane.comp.lang.haskell.libraries |
|---|---|
| Message-ID | <CAKH40QP3ebXyjQK+vRKyiU6u9OoBPtGL+M_Frqo=G_a3gaVgsg@mail.gmail.com> |
Hi, Sometimes, /= is semidecidable and == only cosemidecidable. E.g. Exact Real Arithmetic. Best, Jens On Wed, 20 Oct 2021 at 15:56, Joachim Breitner <[email protected]> wrote: > Hi, > > oh, and I completely forgot to add: > > 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… > > Cheers, > Joachim > > > -- > Joachim Breitner > [email protected] > http://www.joachim-breitner.de/ > > > _______________________________________________ > Libraries mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ Libraries mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries