FW: GHC, functional dependency, rank-2 type
simonpj at microsoft.com
Wed Feb 4 06:42:29 EST 2004
OK, this is a genuine bug, albeit only one that bits with functional
dependencies *and* overlapping instances.
The trouble is that to type (runFoo foo), GHC has to solve the problem:
Given constraint Foo a b
Solve constraint Foo a b'
Notice that b and b' aren't the same. To solve this, just do
improvement and then they are the same. But GHC currently does
That is usually fine, but it isn't here, because it sees that Foo a b is
not the same as Foo a b', and so instead applies the instance decl for
instance Bar a b => Foo a b. And that's where the Bar constraint comes
The Right Thing is to improve whenever the constraint set changes at
all. Not hard in principle, but it'll take a bit of fiddling to do.
Yet another tricky corner for functional dependencies. Thanks for
| However, if we make the classes Foo and Bar seemingly multi-parameter,
| the trouble begins:
| > class Foo a b | a->b
| > class Bar a b | a->b
| > data Obj = Obj
| > instance Bar Obj Obj
| > instance (Bar a b) => Foo a b
| > foo:: (Foo a b) => a -> String
| > foo _ = "works"
| > runFoo:: (forall a b. (Foo a b) => a -> w) -> w
| > runFoo f = f Obj
| *Test> runFoo foo
| Could not deduce (Bar a b) from the context (Foo a b)
| arising from use of `foo' at <interactive>:1
| Probable fix:
| Add (Bar a b) to the expected type of an expression
| In the first argument of `runFoo', namely `foo'
| In the definition of `it': it = runFoo foo
| Why all of the sudden does GHC need the constraint Bar a b? The
| function foo didn't ask for that...
More information about the Glasgow-haskell-bugs