[GHC] #12124: Ambiguous type variable: it's a red herring!
GHC
ghc-devs at haskell.org
Mon Oct 3 08:33:56 UTC 2016
#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
More information about the ghc-tickets
mailing list