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

[Brian Boutel]

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. My remark about "a definition that reflects reality and
bottoms only where equality is undefined" was referring to this
situation.

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. 

Whichever of these was meant, I feel strongly that accomodating this and
other similar changes by weakening the constraints on what Num in
Haskell implies, is going too far. It devalues the Class structure in
Haskell to the point where its purpose, to control ad hoc polymorphism
in a way that ensures that operators are overloaded only on closely
related types, is lost, and one might as well abandon Classes and allow
arbitrary overloading.

--brian





--brian