[Haskell-cafe] type class design

[Ben Millwood]

On Fri, Oct 29, 2010 at 1:33 PM, Tillmann Rendel
<rendel at informatik.uni-marburg.de> 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.