[GHC] #8894: Clean up `Coercible` plumbing

[GHC]

#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