Num class

[Simon Peyton-Jones]

[I'm sending this reply to haskell-cafe.  This one could run and run!]

| > The defaulting mechanism works as follows: If there is an unresolved
| > overloading error on a type variable a, which has as an *only*
| > constraint (Num a), then we take a to be the suitable default.
| 
| This is not what the Haskell 98 Report says. Section 4.3.4:
| 
| "In situations where an ambiguous type is discovered, an ambiguous
| type variable is defaultable if at least one of its classes is a
| numeric class (that is, Num or a subclass of Num) and if all of its
| classes are defined in the Prelude or a standard library (Figures 6--7
| show the numeric classes, and Figure 5 shows the classes defined in
| the Prelude.)"
| 
| I see no good reason for Show superclass of Num.

Quite so.  It's nothing to do with defaulting, and you could legitimately
complain about it.


| I agree that the default mechanism is ugly, and that at least the
| restriction about classes defined in standard libraries should
| be removed.

This was quite a conscious decision by the Haskell committee.  Defaulting
decisions are made silently, and they affect the meaning of the program.
So we consciously imposed quite heavy constraints to make sure that 
silent defaulting doesn't happen much.  (GHC has a flag that warns you
when it is happening.)  You can always write your program by adding an
explicit type signature.

You can argue that this was a poor decision.   Almost certainly there
will be programs for which a more liberal choice would be much more
convenient; perhaps Koen's is one.  So I'm not trying to say "we got it
right", only to explain why it is the way it is.

Making Show a superclass of Num wasn't nearly as conscious a choice.

Simon