[GHC] #15192: Refactor of Coercion

[GHC]

#15192: Refactor of Coercion
-------------------------------------+-------------------------------------
        Reporter:  ningning          |                Owner:  ningning
            Type:  task              |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D4747
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by goldfire):

 About not zonking in coercions in types: I'm worried about violating `Note
 [The tcType invariant]` in TcHsType. I do think we'll need to zonk these.

 An unappealing alternative would be to have `data Coercion = ... |
 ZonkedCo Coercion Type Type FV`; zonking would zonk the types that the
 coercion relates instead of the coercion body. These types would be put
 into a `ZonkedCo`, along with the fvs and the unzonked underlying
 coercion. `zonkTcTypeToType` would then drop the `ZonkedCo` and zonk the
 underlying coercion instead. I don't think this is a good idea, though.

 Back to the main points above: Having an extra constructor for performance
 has a precedent: that's why we have both `TyConApp` and `FunTy`. (Both can
 be encoded by `AppTy`.) The problem is that it will be hard to know when
 to stop playing that game: we will probably always be able to identify
 patterns in individual test cases that would be improved by an extra
 constructor.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15192#comment:27>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler