[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 sweirich):

 Simon,  there is more to it than just "if you apply them to
 representationally-equal arguments you get representationally-equal
 types?" We need to also look at the roles of the parameters in the
 application.

 Consider this example:

 {{{
 type family F a where
    F Moo = Char
    F _      = Int

 newtype T a = MkT (F a)
 newtype U a = MkU (T a)
 }}}

 So T and U are representationally equal, but their parameter has nominal
 role. That means that we can safely conclude


 {{{
 T Moo ~/R U Moo
 }}}
 but it would *not* be safe to say
 {{{
 T Moo ~/R U Int
 }}}
 because then we would have Char ~/R Int.

 That is why I was suggesting the change to TyConAppCo. We're not tracking
 the parameter roles in kinds, so the only place we can look for them is in
 the head of an application.

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