[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 goldfire):

 Right. I forgot that #2110 isn't getting into 7.8. Then, neither should
 this.... which is good, because I agree that maybe some more thought is
 required.

 I was ''not'' suggesting that there be a blanket `fmap coerce --> coerce`
 rule, just that we should add the specific rules for all the individual
 (lawful) `Functor`s that we define. I agree completely that users should
 be free to write unlawful `Functor`s if they wish to do so.

 I don't believe there's a link to earlier discussions on `fmap coerce`
 issue because the discussions happened among actual humans, in an actual
 room, instead of among computers online. It's an amazing thought. In any
 case, I remember one conclusion being a suggestion to add a new method to
 `Functor` being `fmapCoerce :: Coercible a b => f a -> f b`. This would
 have a default implementation of `fmapCoerce = fmap coerce` (no surprise
 there) but could be reimplemented where there would be a performance
 improvement.

 Returning to Edward's comment, I guess I don't understand the limits of
 the RULES mechanism to respond all that intelligently. In Core, anything
 that looks like `fmap coerce` in the source code would look something like
 `$fmapIdForSomeInstance <type parameters> (\x -> x |> co)`. This should be
 easy enough to match at the Core level. If it's impossible to write a RULE
 that desugars to the pattern above, then I think it's a bug (er, feature
 request) in the RULES mechanism, not a call for a change to the `Functor`
 definition.

 Though I'm not dead set against `fmapCoerce` in `Functor`, I believe that
 if we have to add such a thing, then there is a weakness in our design
 somewhere. During the conversations at ICFP, I was unaware of #2110 and
 Joachim's efforts to fix that bug. Now that we have that fixed, I believe
 `fmapCoerce` should be avoidable.

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