Show, Eq not necessary for Num [Was: Revamping the numeric classes]

Patrik Jansson
Wed, 7 Feb 2001 08:35:20 +0100 (MET)

{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

/Patrik Jansson