> This is not an error in the compilers! In this example, it is the
> context of the derived Eq operator that is the problem. In the
> expression NilSet == NilSet, the typing of == is
>
> (==) :: Eq a => a -> a -> Bool
>
> This `a' is instantiated by Set b (to choose a different type
> variable), not Eq b => Set b, resulting in a typing of
>
> Eq(Set b) => Set b -> Set b -> Bool
>
> for your expression. Since the instance for Eq derived by the
> compiler for Set is:
>
> instance Eq a => Eq (Set a) where ...
>
> context reduction will yield a final type of
>
> Eq b => Set b -> Set b -> Bool
>
> The ambiguous Eq b comes from the instance for Eq, not the data
> constructor NilSet. This sort of ambiguity problem is not solved by
> the restriction in the report in constructor contexts.
Thanks for the clarification; I completely agree. The problem is that
I failed to consider that the derived instance implied the context Eq a.
Indeed, when the derived instance is replaced by an explicit
declaration,
instance Eq (Set a) where
x == y = True
then the expression
NilSet == NilSet
is type-correct in both Yale Haskell and glhc.
However, hbi/hbc already rejects the instance declaration:
hbi> data Eq a => Set a = NilSet | ConsSet a (Set a)
hbi> instance Eq (Set a) where
hbi# a == b = True
[42] Bad instance: [83] context not implied Set a ([Eq (a)] by [])
and infers a wrong, nonempty context for the constructor NilSet:
hbi> whatis NilSet;
constructor NilSet :: (Eq a) => Set a
> Moral: If all three compilers disagree with you, you must be wrong :-)
Good point! But if they disagree with each other, then something else
must be wrong ;-)
> John Peterson
> Yale Haskell Project
Thanks,
-Konstantin [[EMAIL PROTECTED]]
