A sample revised prelude for numeric classes
Marcin 'Qrczak' Kowalczyk
12 Feb 2001 07:34:15 GMT
Mon, 12 Feb 2001 17:24:37 +1300, Brian Boutel <firstname.lastname@example.org> 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 * email@example.com http://qrczak.ids.net.pl/
^^ SYGNATURA ZASTĘPCZA