Re: Proposal: Make Eq type class single method

Something I like about the current definition of Eq is that I can choose which method to implement. If (/=) is more convenient, I implement that one and leave the other as default, and viceversa. Am Mo., 25. Okt. 2021 um 16:11 Uhr schrieb Carter Schonwald < carter.schonwald@gmail.com>:

i agree with Tom and Hecate, more strongly: https://github.com/ghc/ghc/blob/98aa29d3fe447cce3407e6864b015892244bb475/lib...

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 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@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries