# Revamping the numeric classes

**Dylan Thurston
**
dpt@math.harvard.edu

*Wed, 7 Feb 2001 13:57:41 -0500*

Other people have been making great points for me. (I particularly
liked the example of Dollars as a type with addition but not
multiplication.) One point that has not been made: given a class
setup like
class Additive a where
(+) :: a -> a -> a
(-) :: a -> a -> a
negate :: a -> a
zero :: a
class Multiplicative a where
(*) :: a -> a -> a
one :: a
class (Additive a, Multiplicative a) => Num a where
fromInteger :: Integer -> a
then naive users can continue to use (Num a) in contexts, and the same
programs will continue to work.[1]
(A question in the above context is whether the literal '0' should be
interpreted as 'fromInteger (0::Integer)' or as 'zero'. Opinions?)
On Wed, Feb 07, 2001 at 06:27:02PM +1300, 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.
*
Why doesn't your argument show that all types should by instances of
Eq and Show? Why are numeric types special?
Best,
Dylan Thurston
Footnotes:
[1] Except for the lack of abs and signum, which should be in some
other class. I have to think about their semantics before I can say
where they belong.