# A sample revised prelude for numeric classes

**Marcin 'Qrczak' Kowalczyk
**
qrczak@knm.org.pl

*12 Feb 2001 07:34:15 GMT*

Mon, 12 Feb 2001 17:24:37 +1300, Brian Boutel <brian@boutel.co.nz> pisze:
>* > class (Additive a) => Num a where
*>* > (*) :: a -> a -> a
*>* > one :: a
*>* > fromInteger :: Integer -> a
*>* >
*>* > -- Minimal definition: (*), one
*>* > fromInteger 0 = zero
*>* > fromInteger n | n < 0 = negate (fromInteger (-n))
*>* > fromInteger n | n > 0 = reduceRepeat (+) one n
*>*
*>* This definition requires both Eq and Ord!!!
*
Only Eq Integer and Ord Integer, which are always there.
>* Why do you stop at allowing addition on Dollars and not include
*>* multiplication by a scalar?
*
Perhaps because there is no good universal type for (*).
Sorry, it would have to have a different symbol.
>* Having Units as types, with the idea of preventing adding Apples to
*>* Oranges, or Dollars to Roubles, is a venerable idea, but is not in
*>* widespread use in actual programming languages. Why not?
*
It does not scale to more general cases. (m/s) / (s) = (m/s^2),
so (/) would have to have the type (...) => a -> b -> c, which is not
generally usable because of ambiguities. Haskell's classes are not
powerful enough to define full algebra of units.
>* It seems that you are content with going as far as the proposal permits,
*>* though you cannot define, even within the revised Class system, all the
*>* common and useful operations on these types. This is the same situation
*>* as with Haskell as it stands. The question is whether the (IMHO)
*>* marginal increase in flexibility is worth the cost.
*
The Prelude class system requires a compromise. There is no single
design which accommodates all needs because Haskell's classes are
not powerful enough to unify all levels of generality in a single
class operation. And even if it was possible, it would be awkward
to use in simpler cases.
--
__("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK