Show, Eq not necessary for Num [Was: Revamping the numeric classes]
Sun, 11 Feb 2001 18:24:33 +1100
On 11-Feb-2001, Brian Boutel <firstname.lastname@example.org> wrote:
> Fergus Henderson wrote:
> > On 09-Feb-2001, Brian Boutel <email@example.com> 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 <firstname.lastname@example.org> | "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.