#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 ekmett): @mpickering: Without the constraint none of the code that actually uses this combinator works at all. Those use sites exploit that extra bit of knowledge passed to the first argument by `instance Conjoined (->)` which knows `p ~ (->)` and therefore can use the first argument. The typical workflow is to do something like {{{#!hs traversed :: Traversable f => IndexedTraversal Int (f a) (f b) a b traversed = conjoined traverse (indexing traverse) }}} `traverse` requires its argument to be a function. `indexing traverse` isn't so picky and works for more choices of `p`. Now using that if you use `traversed` as a simple `Traversal` it'll pick the fast `traverse` path, but if you need access to the numerical indices we put on each member, and use a combinator like `itoListOf` or (`^@..`), then it'll pay the price of computing indices in an extra bit of state. This is equivalent to traversing the original `Traversable` container with `Compose (State Int) f` and bumping the counter after visiting each member, rather than just using your original functor `f`. This is much much slower. `traversed` and `indexing traverse` should be indistinguishable for users, except for the fact that the former is much much faster for the common case. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12466#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler