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

[Fergus Henderson]

On 11-Feb-2001, Brian Boutel <brian@boutel.co.nz> wrote:
> Fergus Henderson wrote:
> > 
> > On 09-Feb-2001, Brian Boutel <brian@boutel.co.nz> wrote:
> > > Patrik Jansson wrote:
> > > >
> > > > 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.
> > ...
> > >
> > > There is nothing trivial or ugly about a definition that reflects
> > > reality and bottoms only where equality is undefined.
> > 
> > I disagree.  Haskell is a statically typed language, and having errors
> > which could easily be detected at compile instead being deferred to
> > run time is ugly in a statically typed language.
> 
> There may be some misunderstanding here. If you are talking about type
> for which equality is always undefined, then I agree with you, but that
> is not what I was talking about. I was thinking about types where
> equality is defined for some pairs of argument values and undefined for
> others - I think the original example was some kind of arbitrary
> precision reals.

The original example was treating functions as a numeric type.  In the
case of functions, computing equality is almost always infeasible.
But you can easily define addition etc. pointwise:
	
	f + g = (\ x -> f x + g x)

> Returning to the basic issue, I understood the desire to remove Eq as a
> superclass of Num was so that people were not required to implement
> equality if they did not need it, not that there were significant
> numbers of useful numeric types for which equality was not meaningful. 

The argument is the latter, with functions as the canonical example.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.