[GHC] #8767: Add rules involving `coerce` to the libraries

[GHC]

#8767: Add rules involving `coerce` to the libraries
-------------------------------------------------+-------------------------
        Reporter:  nomeata                       |            Owner:
            Type:  task                          |           Status:  new
        Priority:  normal                        |        Milestone:  7.8.1
       Component:  libraries/base                |          Version:
      Resolution:                                |  7.8.1-rc2
Operating System:  Unknown/Multiple              |         Keywords:
 Type of failure:  None/Unknown                  |     Architecture:
       Test Case:                                |  Unknown/Multiple
  tests/simplCore/should_run/T2110.hs            |       Difficulty:
        Blocking:                                |  Unknown
                                                 |       Blocked By:  8718
                                                 |  Related Tickets:  #2110
-------------------------------------------------+-------------------------

Comment (by ekmett):

 That is why I think any solution that works in a polymorphic setting or
 one too big to `INLINE` really involves adding something to `Functor` that
 permits the lifting of coercions for lawful functors. `fmapCoerce` was the
 first such candidate. It just isn't strong enough.

 A more viable alternative is to add something like `liftCoercion ::
 Functor f => Coercion a b -> Maybe (Coercion (f a) (f b))` to `Functor`,
 analogous to the precedent of how `(<$)` is already added there to permit
 faster 'scrubbing' of functor contents with increased sharing.

 This'd permit `liftCoercion Coercion = Just Coercion` to be written (or
 generated) as a witness for the representational or phantom role of the
 argument, and it could be used inside an `fmapCoerce` to lift over complex
 polymorphic functors.

 There are admittedly a lot of moving parts in such a design, though, and
 even ''that'' design as I recall isn't sufficient to address more
 complicated transformers and recursive data types, so there is still work
 to be done.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8767#comment:15>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler