#8894: Clean up `Coercible` plumbing -------------------------------------+------------------------------------ Reporter: nomeata | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: #8904 -------------------------------------+------------------------------------ Comment (by simonpj): Thanks for doing this. I think it's clearly better. Actually I think we can go two steps better still. * Suppose the declaration of `Coercible` in `GHC.Types` is actually {{{ class Coercible a b }}} Then, when compiling `GHC.Types`, the code we produce for the declaration will still include code for the data constructor of the dictionary (with no value fields), although with a different name, built with `mkClassDataConOcc`. But that is fine, provided we adjust the `coercibleDataConName` in `TysWiredIn` to match; and that would probably be a good piece of consistency anyway. * Once that is done, we can declare `coerce` in `GHC.Types` rather than `GHC.Prim`: {{{ coerce :: Coercible a b => a -> b coerce = error "You should not be calling me" }}} * And it might be possible to move both these definitions to `Data.Coerce` which would be better still. Haddock will display the right result for every module, and the documentation will all be in one place in `Data.Coerce`. All this should work because `Coercible` and `coerce` are "wired-in" things, and so they are never written to an interface file. Importing modules just use GHC's built-in knowledge of them. It's fine provided the code generated by compiling the definitions matches the wired-in knowledge. Does that make sense? Simon -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8894#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler