#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 mpickering): Replying to [comment:16 ekmett]:
So am I correct in guessing that this causes us to fail for the `Conjoined` class in `lens`?
Yes this is where the example was reduced from.;
This is a rather big huge of the optimization story in `lens`, as we use
it to avoid fiddling around with updating indices when the user isn't using them. This can make a 100x difference in performance for user code, so it isn't a trivial thing to throw away. If this suddenly isn't legal any more I'm really not sure what the heck we're going to do. It seems that removing the constraint would preserve existing performance gains? Is the constraint used for something more than ensuring that only `p ~ (->)` can use the first argument and all other instances must use the default method? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler