Marcin 'Qrczak' Kowalczyk
18 Oct 2000 20:02:18 GMT
Wed, 18 Oct 2000 12:57:56 +0200 (MET DST), Koen Claessen <email@example.com> 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
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
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 * firstname.lastname@example.org http://qrczak.ids.net.pl/
^^ SYGNATURA ZASTĘPCZA