Re: Make Eq type class single method

As in so many other cases, documenting the design decisions (that lead 
to (/=) in Eq) would have helped [even for the initial reflection on 
this design].

I see that in another thread there are reasons brought forward in favor 
of (/=).  So if the outcome of this discussion is "no change", the 
reasons should be added to the documentation of the Eq class.

--Andreas

On 2021-10-20 16:48, Brandon Allbery wrote:
>     I'm finding it hard to think of a case where (/=) would be any
>     easier to define than (==).
> 
> 
> On Wed, Oct 20, 2021 at 10:43 AM Tom Ellis 
> <[email protected] 
> <mailto:[email protected]>> wrote:
> 
>     On Wed, Oct 20, 2021 at 04:39:21PM +0200, Joachim Breitner wrote:
>      > 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?
> 
>     Perhaps sometimes it is easier to define (/=) and use the default
>     definition of (==) in terms of it?

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