I would like some clarification about the circumstances under which defaults
are applied. The relevant section of the Haskell report is on P49, and
reads
as follows (the annotations are mine):
"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, pages 83–84 show the
numeric classes, and Figure 5, page 77, shows the classes defined in the
Prelude.) Each defaultable variable is replaced by the first type in the
default list that is an instance of all the ambiguous variable’s classes.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It is a static error if no such type is found."
I'm not sure what the underlined phrases mean: what are the classes of an
ambiguous variable? I suspect that this language dates back to old versions
of Haskell that insisted on class constraints of the form (C a) in contexts,
where "C" is the name of a class and "a" is a type variable. In that
setting,
the text above makes good sense and it is entirely reasonable to say that
"C"
is one of "a"'s classes. But with Haskell 98, we can have constraints of
the
form C (a t1 ... tn) where "a" is still a type variable, but "t1", ..., "tn"
are arbitrary types. Suppose that an ambiguous variable "v" appears in one
of those types ... is "C" still to be regarded as one of "v"'s classes? If
so, then the second underlined part above doesn't make a lot of sense: if
"C"
is actually "Monad", for example, then no choice of "v" (necessarily of kind
*)
will be an instance of "Monad" (whose instances have kind * -> *). And even
if "C" is a class of kind *, then it seems quite illogical to require "C v"
to hold just because "v" appears ambiguously in some constraint of the form
"C (a v)".
Current versions of Hugs 98 avoid this problem by adding an extra, implicit
condition to the definition of defaulting, marked with ***** in the
following:
If "v" is an ambiguous variable, and
if "v" appears only in constraints of the form "C v", and *****
if one of "v"'s classes is numeric, and
if all of "v"'s classes are defined in the prelude or std libraries, and
if one of the default types is an instance of all those classes,
then "v" can be defaulted.
Notice that this extra condition, *****, is necessary to make sense of the
phrase "v"'s classes in subsequent lines, as I've outlined above.
I'd be grateful for any clarification. Is there something wrong with my
interpretation of the report, the behavior of Hugs 98, the report itself,
or some subset of these three?
All the best,
Mark
PS. If you like a concrete example where this makes a difference, here's
a simply (but admittedly bizarre) example that Hugs rejects, where others
might expect defaulting to kick in:
foo x | c==c = c >> return x
where c = return 0
The ambiguous type for this example is:
(Monad a, Eq (a b), Num b) => c -> a c
