[GHC] #8503: New GeneralizedNewtypeDeriving check still isn't permissive enough

[GHC]

#8503: New GeneralizedNewtypeDeriving check still isn't permissive enough
-------------------------------------+------------------------------------
        Reporter:  goldfire          |            Owner:  goldfire
            Type:  bug               |           Status:  new
        Priority:  normal            |        Milestone:
       Component:  Compiler          |          Version:  7.7
      Resolution:                    |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown      |       Difficulty:  Unknown
       Test Case:                    |       Blocked By:
        Blocking:                    |  Related Tickets:
-------------------------------------+------------------------------------

Comment (by goldfire):

 I agree with Stephanie -- the rule Simon was looking at in core-spec
 (Co_AppCo, p. 10) is that way for a good reason.

 Why eta-reduce? Because it allows for more lifting of newtype coercions,
 via the `Coercible` mechanism. For example, if we don't eta-reduce

 {{{
 newtype NTMaybe a = MkNT (Maybe a)
 }}}

 then we couldn't derive, say `StateT Int NTMaybe a ~R StateT Int Maybe a`.
 So, we don't need eta-reduction as much as maybe we once did, but it's
 still useful.

 One other alternative is to have the cake and eat it too: a newtype
 declaration like the one for `NTMaybe` can create ''two'' axioms: one eta-
 reduced and one not. There would have to be some logic to choose which
 axiom to use, but this would allow for all the constructions that we might
 want. (Strawman implementation: always use the eta-reduced version, except
 in GND and in `Coercible` code where we need the extra role info.)

 I'm personally not a big fan of the generalization of `TyConAppCo`.
 Stephanie's proposal means that the `TyConAppCo` would have to store two
 `TyCon`s and a coercion between them, and all the code that thinks about
 `TyConAppCo`s would now have to consider the possibility that the two
 `TyCon`s are different.

 But, after all this, I still think I favor my original idea: allow
 oversaturated `AxiomInstCo`s, and store extra role information in
 `CoAxiom`s accordingly. Can we think of reasons why this is bad? We
 already allow oversaturated `TyConAppCo`s (in fact, we require them to be
 oversaturated, as a `TyConAppCo` can't be on the left of an `AppCo`). We
 would introduce a similar invariant between `AxiomInstCo` and `AppCo`.

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