#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): The `fmapCoerce` solution turned out not to be powerful enough to handle things like `Compose f g` while `g` remains polymorphic or many monad transformers. We vacillated between a few other solutions that let you add a different member to Functor that could lift coercions by the end of ICFP, but with GHC 7.8 happening "any day now" at the time we agreed to just punt on it until we could give it due deliberation. My main point was that if the code is still polymorphic in the functor and complicated enough not to inline into a place where that rule can fire the rule doesn't help. We encourage people to write very polymorphic code. e.g. It solves many of the bugaboos people trot out about monad transformers and the like if you avoid picking a concrete instance until the last second. I'd be really sad to see that part of our culture die to get a few zero-cost newtype applications. Anyways, not sure what the right solution is yet, but I did want to interject that whatever it is, `fmapCoerce` isn't it. ;) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8767#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler