Make Eq type class single method

[Jens Blanck]

Hi,

Sometimes, /= is semidecidable and == only cosemidecidable. E.g. Exact Real
Arithmetic.

Best,
Jens

On Wed, 20 Oct 2021 at 15:56, Joachim Breitner <mail at joachim-breitner.de>
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
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20211020/04ee506e/attachment.html>