Num class

Marcin 'Qrczak' Kowalczyk qrczak@knm.org.pl
18 Oct 2000 20:02:18 GMT


Wed, 18 Oct 2000 12:57:56 +0200 (MET DST), Koen Claessen <koen@cs.chalmers.se> pisze:

> 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.

Eq makes a little more sense, but could be dropped too. It would be
inferred separately when a numeric literal is used in a pattern.

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

Clean has per-class defaults. I don't know how conflicting defaults
coming from different class constraints should be solved, or what about
multiparameter classes, and whether extending the defaulting mechanism
is a good idea at all. But since we don't have anything better...

-- 
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK