Re: [Haskell-cafe] type class design

On Tue, Dec 21, 2010 at 4:30 AM, Jean-Marie Gaillourdet wrote:

Hi,

sorry for answering to such an old thread.

David Menendez writes:

...

On Fri, Oct 29, 2010 at 8:33 AM, Tillmann Rendel wrote:

...

Hi,

Uwe Schmidt wrote:

...

In the standard Haskell classes we can find both cases, even within a single class.

Eq with (==) as f and (/=) as g belongs to the 1. case

Note that the case of (==) and (/=) is slightly different, because not only can (/=) be defined in terms (==), but also the other way around. The default definitions of (==) and (/=) are mutually recursive, and trivially nonterminating. This leaves the choice to the instance writer to either implement (==) or (/=). Or, for performance reasons, both.

While I understand the argument in general, I've never understood why it applies to Eq. Are there any types where it is preferable to define (/=) instead of (==)?

Yes for infinite data structures.

How so? For an infinite structure, x == y will return False or not return and x /= y will return True or not return. We still have x /= y = not (x == y) and I don't see any reason why one would prefer to define (/=) instead of (==). -- Dave Menendez http://www.eyrie.org/~zednenem/