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

Brian Boutel brian@boutel.co.nz
Fri, 09 Feb 2001 10:37:46 +1300


Patrik Jansson wrote:
>
> 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.
> 

There is nothing trivial or ugly about a definition that reflects
reality and bottoms only where equality is undefined.

Of course, if you do not need to apply equality to your "numeric" type
then having to define it is a waste of time, but consider this:

- Having a class hierarchy at all (or making any design decision)
implies compromise.
- The current hierarchy (and its predecessors) represent a reasonable
compromise that meets most needs.
- Users have a choice: either work within the class hierarchy and accept
the pain of having to define     things you don't need in order to get
the things that come for free, or omit the instance declarations    and
work outside the hierarchy. In that case you will not be able to use the
overloaded operator symbols   of the class, but that is just a matter of
concrete syntax, and ultimately unimportant.

--brian