Revamping the numeric classes
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
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.
(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?
 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.