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@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@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