[GHC] #12466: Typechecker regression: Inaccessible code in a type expected by the context

[GHC]

#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