#10532: Unnecessary constraints when using overlapping instances -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: invalid | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: Consider what happens, in your modified code with overlapping instances, when you call `f` thus: `f (4::Int)`. What result do you expect? You might say: 1. The instance `Foo Int` clearly says that `foo` is the identity function on `Int`. I'm giving it an `Int` so `f 4` should return `4`. 2. Or you might say: when I compiled the code for `f`, GHC had to choose which instance to use, of the two available. Since the constraint is `Foo a`, and GHC knows nothing about `a` it must choose the `Foo a` instance. Result, `f 4` returns 5. This incoherence is what GHC is complaining about. If it can't make a unique choice, it decides not to decide, and rejects the program instead. If it silently chose (2), which I think you intend, then if you replaced the call `(f 4)` with the result of inlining `f`, thus `(foo 4)`, the result of the program would change. This has been GHC's behaviour (and Hugs) ever since we introduced overlapping instances. The flag `-XIncoherentInstances` switches off this behaviour, and does (2). Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10532#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler