Make Eq type class single method

[David Feuer]

This sounds good to me. Having (/=) be a method has always seemed like a
bit of a wart, since it's hard to imagine either a reason to define it
explicitly or a reason to want it in a dictionary.

On Wed, Oct 20, 2021, 10:40 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi list,
>
> I am revisiting some educational material about Haskell, and I stumble
> over something that I keep stumbling over. I thought there was prior
> discussion, but I couldn’t find it (operators hard hard to google for).
>
> Why does Eq have a (/=) method?
>
> Semantically, I don’t see a reason why an instance might want to behave
> differently than the default method. And (in contrast to, say, Ord), I
> would be surprised if there are noticable performance benefits to be
> gained from implementing (/=) separately.
>
> On the other hand, this is likely the first time a learner will
> encounter a class with default methods, and it’s awkward to explain
> “this mechanism is useful if you can have an optimized implementation,
> but, eh, here it isn’t really possible”.
>
> If we’d design the language now, would we include (/=) as a method?
>
>
> 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.
>
> WDYT?
> 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/7422cd7a/attachment.html>