On Fri, Oct 29, 2010 at 1:33 PM, Tillmann Rendel <[email protected]> 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. _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
