RE: ambiguity problem

GHC is cautious about complaining about ambiguity.  For example, you
say:
| g :: Foo a b => a
| g = undefined

should be rejected.  But here is a perfectly legal call:

        f :: Int
        f = g

        instance Foo Int b

Here, I'm calling 'g' at types (Int, t) for some unknown type t; that
gives rise to
the constraint (Foo Int t), which is discharged by the instance
declaration.   Another possibility might be

        instance Baz Int b => Foo Int b where ..
        class Baz a b | a -> b where ...
        instance Baz Int Bool where ...

Now the (Foo Int t) constraint leads to a (Baz Int t) constraint, and
that means that 't' must be Boo.

Conclusion: it would be premature to reject g at its definition. In
fact, GHC only rejects as ambiguous functions that cannot be legally
called from any context.  For example
        h :: Show a => b -> b
any call will give rise to the (Show a) constraint, with no other
information about 'a' at all, ever.  (Oh, you could imagine an instance
declaration "instance Show a where ...", but that's not legal Haskell
even with extensions, so we neglect that possibility.)

GHC's rule (not documented I'm afraid) is this.  Consider the type

        f :: (C a b, D c c, E b c, F d) => a->a

1. Find the free type variables of the part after the arrow, namely {a}.
2. For any constraint that mentions any variable in the set, add to the
set
        any other variables mentioned in that constraint. For example,
(C a b)
        mentions a, so add b to the set, giving {a,b}
3. Repeat step 2 to a fixed point.  For example, (E b c) mentions b, so
add c to
        the set, giving {a,b,c}
4.  Any constraint that mentions type variables not in the set is
definitely ambiguous.
        In this example, the only definitely ambiguous constraint is (F
d)


This rule is pretty lax.  It allows many functions that are probably
ambiguous to pass.  But that's ok because YOU'LL GET A TYPE ERROR WHEN
YOU CALL THE FUNCTION.  For example, GHC permits 
        g :: Foo a b => a
        g = undefined
but when you call it (say (g :: Int)), you'll get a complaint "cant
satisfy constraint 
(Foo Int b)".

Failing to reject an ambiguous type signature may defer type errors but
it's perfectly sound.  GHC therefore only rejects *absoulutely
definitely* ambiguous type signatures, leaving the others for the call
sites.


This should really be documented, I suppose.

Simon

  

| -----Original Message-----
| From: glasgow-haskell-bugs-admin@xxxxxxxxxxx
[mailto:glasgow-haskell-bugs-
| admin@xxxxxxxxxxx] On Behalf Of Martin Sulzmann
| Sent: 22 April 2003 09:42
| To: glasgow-haskell-bugs@xxxxxxxxxxx
| 
| Hi,
| 
| I'm using
| 
|  ghci --version
| The Glorious Glasgow Haskell Compilation System, version 5.04.2
| 
| ghci -fglasgow-exts
| 
| doesn't seem to report ambiguity of type schemes.
| 
| Take a look at the following program.
| 
| class Bar a b | a -> b where
|   bar :: a -> b
| 
| class Foo a b  where
|   foo :: Bar b c => a -> c
| -- ambiguous
| -- should be foo :: Bar b c => a -> b
| 
| g :: Foo a b => a
| g = undefined
| 
| -- ambiguous
| 
| No ambiguity error is reported. This seems like a bug.
| 
| Martin
| 
| _______________________________________________
| Glasgow-haskell-bugs mailing list
| Glasgow-haskell-bugs@xxxxxxxxxxx
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs