#12124: Ambiguous type variable: it's a red herring! -------------------------------------+------------------------------------- Reporter: drb226 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): For the Description, what is happening is this: * The ill-arity'd pattern `Whoops a -> ..` makes the typechecker emit an error message and fail with a hard error; rightly so. * Usually the typing constraints arising from the failing computation would be discarded. But as a short-cut for a common case, GHC does not begin a new implication constraint for the RHS of `foo`, because it has no tyvars and no given constraints. * So the `Monad a` constraint arising from the call of `return` is accumulated into the top-level constraints of the whole program; so after recovering from the error GHC tries to solve the constraint. Two possible solutions * Remove the special case. That looks OK, but it'd mean that we might solve `(Num Int)` repeatedly in different function definitions. CSE can common-up later, but it's just more work. * In the special case, accumulate constraints in a separate variable, and union them into the outer context only if the typecheck succeeds. Not hard to do; I think this is probably best. Thanks for the accurate report! Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12124#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler