#12466: Typechecker regression: Inaccessible code in a type expected by the context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 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 simonpj): I agree with your reasoning, but it's quite painful to implement the 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? Currently GHC tries to do co/contra checking for subsumption checking. If we just used equality on the LHS of arrow, I think the negative/positive problem would disappear. Which is an intesting strike in favour of that approach. That would mean that this would fail: {{{ f :: (Int -> Int) -> Int g :: (forall a. a-> a) -> Int g = f }}} On the other hand, with the same signatures {{{ g x = f x }}} would succeed. The current co/contra subsumption is clever, but tricky... eg every foray into impredicative polymorphism gives up on it. Maybe we should give up on it now. Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:26 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler