#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