A sample revised prelude for numeric classes

[Marcin 'Qrczak' Kowalczyk]

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