Revisiting the Numeric Classes
Introduction
The Prelude for Haskell 98 offers a wellconsidered set of numeric classes
which covers the standard numeric types
(Integer
, Int
, Rational
, Float
, Double
, Complex
) quite well.
But they offer limited extensibility and have a few other flaws.
In this proposal we will revisit these classes, addressing the following concerns:

The current Prelude defines no semantics for the fundamental operations.
For instance, presumably addition should be associative
(or come as close as feasible),
but this is not mentioned anywhere.

There are some superfluous superclasses.
For instance, Eq
and Show
are superclasses of Num
.
Consider the data type
data IntegerFunction a = IF (a > Integer)
.
One can reasonably define all the methods of Algebra.Ring.C
for
IntegerFunction a
(satisfying good semantics),
but it is impossible to define nonbottom instances of Eq
and Show
.
In general, superclass relationship should indicate
some semantic connection between the two classes.

In a few cases, there is a mix of semantic operations and
representationspecific operations.
toInteger
, toRational
,
and the various operations in RealFloating
(decodeFloat
, …)
are the main examples.

In some cases, the hierarchy is not finelygrained enough:
Operations that are often defined independently are lumped together.
For instance, in a financial application one might want a type “Dollar”,
or in a graphics application one might want a type “Vector”.
It is reasonable to add two Vectors or Dollars,
but not, in general, reasonable to multiply them.
But the programmer is currently forced to define a method for (*)
when she defines a method for (+)
.
In specifying the semantics of type classes,
I will state laws as follows:
(a + b) + c === a + (b + c)
The intended meaning is extensional equality:
The rest of the program should behave in the same way
if one side is replaced with the other.
Unfortunately, the laws are frequently violated by standard instances;
the law above, for instance, fails for Float
:
(1e20 + (1e20)) + 1.0 = 1.0
1e20 + ((1e20) + 1.0) = 0.0
For inexact number types like floating point types,
thus these laws should be interpreted as guidelines rather than absolute rules.
In particular, the compiler is not allowed to use them for optimization.
Unless stated otherwise, default definitions should also be taken as laws.
Thanks to Brian Boutel, Joe English, William Lee Irwin II, Marcin
Kowalczyk, Ketil Malde, Tom Schrijvers, Ken Shan, and Henning
Thielemann for helpful comments.
Usage
Write modules in the following style:
{# LANGUAGE RebindableSyntax #}
module MyModule where
... various specific imports ...
import NumericPrelude
Importing NumericPrelude
is almost the same as
import NumericPrelude.Numeric
import NumericPrelude.Base .
Instead of the NoImplicitPrelude
pragma
you could also write import Prelude ()
but this will yield problems with numeric literals.
There are two wrapper types that allow types
to be used with both Haskell98 and NumericPrelude type classes
that are initially implemented for only one of them.
Scope & Limitations/TODO

It might be desireable to split Ord
up into Poset
and Ord
(a total ordering).
This is not addressed here.

In some cases, this hierarchy may not yet be finegrained enough.
For instance, time spans (“5 minutes”) can be added to times (“12:34”),
but two times are not addable. (“12:34 + 8:23”)
As it stands,
users have to use a different operator for adding time spans to times
than for adding two time spans.
Similar issues arise for vector space et al.
This is a consciouslymade tradeoff, but might be changed.
This becomes most serious when dealing with quantities with units
like length/distance^2
, for which (*)
as defined here is useless.
(One way to see the issue: should
f x y = iterate (x *) y
have principal type
(Ring.C a) => a > a > [a]
or something like
(Ring.C a, Module a b) => a > b > [b]
?)

I stuck with the Haskell 98 names.
In some cases I find them lacking.
Neglecting backwards compatibility, we have renamed classes as follows:
Num > Additive, Ring, Absolute
Integral > ToInteger, IntegralDomain, RealIntegral
Fractional > Field
Floating > Algebraic, Transcendental
Real > ToRational
RealFrac > RealRing, RealField
RealFloat > RealTranscendental
Additional standard libraries might include Enum
, IEEEFloat
(including the bulk of the functions in Haskell 98’s RealFloat
class),
VectorSpace
, Ratio
, and Lattice
.