#4952: Typechecking regression
----------------------------------------+-----------------------------------
Reporter: igloo | Owner:
Type: bug | Status: new
Priority: highest | Milestone: 7.0.2
Component: Compiler (Type checker) | Version: 7.0.1
Keywords: | Testcase:
Blockedby: | Difficulty:
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
----------------------------------------+-----------------------------------
Comment(by dimitris):
OK I think I see what's going on. We get a given from the instance
[Given] MonadError e1 m (e1 is a
skolem)
And an implication from the definition of withDirectory:
MonadError e2 (M m) => [Wanted] MonadError $e (M m) ($e is a
unification var)
Now, if we first improve $e ~ e2 then we will unify $e := e2, and then we
will apply
the top-level instance declaration which will then leave us with an
unsolvable goal:
[Wanted] MonadError e2 m
If instead we first apply the top-level instance, we are left with a
simpler
[Wanted] MonadError $e m
which will improve with the outer given and become solvable!
But it is not at all clear to me that one strategy is better than the
other in general ... It just seems wrong that the two *given* skolems e1
and e2 are not
equal, but fundeps have no way to express that. If the fundeps were
encoded with
equality superclasses we'd be just fine because we would get that e1 ~ e2
I believe.
Anyway, a quick (perhaps non-functional) solution is to remove the class
context from the definition of withDirectory ...
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4952#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
