On Fri, Oct 29, 2010 at 1:33 PM, Tillmann Rendel wrote:

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.

I find these sorts of defaults deeply unsatisfying: particularly, suppose I do newtype Foo = Foo Integer deriving (Eq, Show) instance Num Foo where Foo a + Foo b = Foo (a + b) fromInteger = Foo expr = Foo 3 - Foo 2 That I haven't defined implementations for (-) or negate will not even get me a compiler warning, let alone a static error: it will just stack overflow or spin endlessly on expr. This kind of bug is notoriously difficult to track down. I'm not sure how to handle this better, though. A compiler that automatically calculated minimal complete definitions would be nice, but relatively complicated. It might be more sensible to just take all efficiency methods out of classes, and use a mechanism like rewrite rules to give an efficient implementation where possible.

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. Cheers, Jean-Marie

On 30 October 2010 22:44, Uwe Schmidt wrote:

...

Another possible argument: large type classes can look daunting for both implementors and users, even if only one or two methods need to be defined for a minimal instantiation (I'm tring to work out what to do here myself, as I have some typeclasses that for efficiency reasons it might be nice to have more methods in the class, but it makes it a little overwhelming).

But by putting just a small part of the interface into the class does not make the live of a user any simpler. The user usually has to know the whole interface of the module. Or am I missing something?

Well, if you have a small class then it's possible for you to split up the different types of functions to be in different modules into more logical sub-types, etc. Also, I find the documentation for the list functions in the Prelude and Data.List easier to read than the ones in ListLike [1], partially because typical documentation for class methods is typically smaller and more compact than the stand-alone functions. [1]: http://hackage.haskell.org/package/ListLike -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com