Revamping the numeric classes

[Dylan Thurston]

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.