No, no, no! GHC is right and Hugs is wrong. This is a well known bug
in Hugs. It doesn't have anything to do with 4.5.1 - it goes like
this:
module Foo where
x = 13
y = x :: Bool
instance Num Bool
First, the type of x is inferred to be Num a => a. No arguments here!
But at generalization time, it is NOT set to All a: Num a => a. The
monomorphism restriction says that this must have a monomorphic type,
but we don't know what that type is yet - uses of the variable x may
`pin down' it's type. Now Hugs, at this point, gives up and applies
defaulting. That's wrong: you have to wait until type inference for
the module is complete. Also, note that if x is exported, uses of x
outside the module won't influence it's type - only those in the
module (but not necessarily the same decl group!!).
Anyway, we typecheck y and get the SAME typevariable that defines x.
That gets unified with Bool. Aha! The type of x is now Bool. That's
monomorphism and everyone is happy (except Jeff!). But that's the way
it's supposed to work - the uses of a monomorphicly typed value affect
the type of the value. Here, the use of x sets its type to Bool.
This happened because of the monomorphism restriction, not due to
dependency analysis. Furthermore, this shouldn't be troubling: the
compiler has chosen a completely appropriate type for x. It's not the
most general, but that's the price you pay to avoid type ambiguity.
The report has all of the information there. It's really not within
the scope of the report to serve as a tutorial for the odd bits of the
typechecking process, although we've tried.
Don't mess with Simon - he's always right!
John
