I agree with your reasoning, but it's quite painful to implement the
#12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:26 simonpj]: positive/negative distinction (given the way the constraint solver works). Anything is possible, but this all seems a bit exotic, so I'm inclined to look for a simple solution.
I think it would be simple to:
* Not complain about inaccessible code in instance methods
Would that do?
That doesn't seem likely to solve the problem in general, and leads to an odd inconsistency. Unfortunately, I don't know enough about type checking to understand the problem with the positive/negative approach. If you can't make that work, I would personally prefer dialing back the inaccessible code error to a warning and being stingier about emitting it. Having to manually defer GHC's checking using `Dict` and such always struck me as unnatural and potentially fragile. If I state ex falso, I'm usually doing it on purpose. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:30 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler