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 <
[email protected]>:

> 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 <[email protected]>
> 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
>>   [email protected]
>>   http://www.joachim-breitner.de/
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> [email protected]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> [email protected]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>

_______________________________________________
Libraries mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries