#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