{I'm diverting this discussion to haskell-cafe.} [I am not sure a more mathematically correct numeric class system is suitable for inclusion in the language specification of Haskell (a library would certainly be useful though). But this is not my topic in this letter.] On Wed, 7 Feb 2001, Brian Boutel wrote:
* Haskell equality is a defined operation, not a primitive, and may not be decidable. It does not always define equivalence classes, because a==a may be Bottom, so what's the problem? It would be a problem, though, to have to explain to a beginner why they can't print the result of a computation.
The fact that equality can be trivially defined as bottom does not imply that it should be a superclass of Num, it only explains that there is an ugly way of working around the problem. Neither is the argument that the beginner should be able to print the result of a computation a good argument for having Show as a superclass. A Num class without Eq, Show as superclasses would only mean that the implementor is not _forced_ to implement Eq and Show for all Num instances. Certainly most instances of Num will still be in both Show and Eq, so that they can be printed and shown, and one can easily make sure that all Num instances a beginner encounters would be such. As far as I remember from the earlier discussion, the only really visible reason for Show, Eq to be superclasses of Num is that class contexts are simpler when (as is often the case) numeric operations, equality and show are used in some context. f :: Num a => a -> String -- currently f a = show (a+a==2*a) If Show, Eq, Num were uncoupled this would be f :: (Show a, Eq a, Num a) => a -> String But I think I could live with that. (In fact, I rather like it.) Another unfortunate result of having Show, Eq as superclasses to Num is that for those cases when "trivial" instances (of Eq and Show) are defined just to satisfy the current class systems, the users have no way of supplying their own instances. Due to the Haskell rules of always exporting instances we have that if the Num instance is visible, so are the useless Eq and Show instances. In the uncoupled case the users have the choice to define Eq and Show instances that make sense to them. A library designer could provide the Eq and Show instances in two separate modules to give the users maximum flexibility. /Patrik Jansson