#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