Proposal: Make Eq type class single method

[Carter Schonwald]

i agree with Tom and Hecate,
more strongly:
https://github.com/ghc/ghc/blob/98aa29d3fe447cce3407e6864b015892244bb475/libraries/ghc-prim/GHC/Classes.hs#L142-L150

the current definition DOES NOT require defining both.

as it currently stands, you only need to define one of '==' *XOR*  '/='

this actually suggests an interesting and DIFFERENT ecosystem improvement,
(ignoring IEEE non-signalling NANs),
namely we add support for XOR to minimal pragma syntax and issue a warning

perhaps something like adding *(XOR "reason String" clauseExpr1
clauseexpr2)* ?

in which case for the Eq  the example useage would be something like

{-# MINIMAL ((== ) || (/=))  & (XOR "it is seldom correct to define both ==
and /= explicitly, please be careful!" (==) (/=)) #-}

this also seems like a "newish contributor" ish friendly improvement in our
minimal pragma facilities that could be useful for other examples?

On Mon, Oct 25, 2021 at 9:29 AM Oliver Charles <ollie at ocharles.org.uk>
wrote:

> I'd like to also add that there is another benefit - correctness.
>
>
>    - Eq is easier to get right/harder to get wrong. Currently if you hand
>    roll Eq, you could potentially implement both == and /=, but get one or the
>    other wrong. With only == as a method, as long as you get that right, you
>    are guaranteed that /= is also right.
>
>
> On Mon, 25 Oct 2021, at 2:22 PM, Joachim Breitner wrote:
>
> Hi,
>
> ah, yes, let me summarize my main motivation (perf benefits were just a
> side-benefit I was hoping for):
>
> You can’t implement (/=) faster than (==) (up to, in the worst case,
> the cost of a single `not`, which often gets optimized away anyways).
>
> As such, having (/=) in Eq was a (small) mistake back then, and it’s
> worth fixing.
>
> There is one time cost of asking developers to _remove_ code. But code
> that was probably not worth writing in the first place! And I don’t
> blame them, the Eq class _invites_ writing that code.
>
> Then the benefits are twofold:
>
> * No more awkwards explanations about silly things in the likely first
>    type class that developers care about.
>
> * Less code to read, maintain, compile in all the libraries that _do_
>    define (/=) right now.
>
> * Devs who instantiate Eq in the future will not be tricked into
>    wondering if they need to implement (/=) and why.
>
> So even if “helps teaching beginners” doesn’t beat “having to bug
> maintainers”, then maybe the second point (“saving all develpers time
> and effort in the future”) does?
>
> 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
>
>
> _______________________________________________
> 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/20211025/0b42dd5a/attachment.html>