Mon, 12 Feb 2001 17:24:37 +1300, Brian Boutel
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