#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