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

 Yes, I agree, sadly.

 Simon PJ and I (in a phone call) thought that we could solve all our
 problems with `topNormaliseType_maybe`, which "evaluates" out any newtypes
 and type functions that appear ''at the top'' of a type. If there is no
 way to reduce a type at the top level, the function fails. Because the
 `Coercible` code really only examines the top level, we thought this was
 sufficient. However, it's not, because of the example you (nomeata) give,
 with `RecNT` and `RecNT2`.

 My only thought now for how to do this is to record in the wanted
 constraint which newtypes have been expanded, perhaps using the
 `checkRecTc` technology. This would mean either creating a new constructor
 for `Ct` or a new field somewhere. Perhaps creating a new constructor
 isn't so bad -- that's how nominal equality is handled. Canonicalisation
 can then convert a normal class-based constraint into the new `CCoercible`
 or something. I still think there is hope here, and I do think we should
 strive to include recursive newtypes in this approach.

 In my attempt to fix this all, I've done some refactoring in
 `getCoercibleInst`. You can see my work at
 [http://github.com/goldfirere/ghc my github repo], branch `coerce`. That
 branch also introduces a `GenCoercion` class containing `Coercion` and
 `TcCoercion`. That may or may not be a good idea, but it worked nicely
 with `topNormaliseType_maybe`, which has to sometimes produce a `Coercion`
 and sometimes a `TcCoercion`.

 I've also discovered that `Coercible` really ought to be poly-kinded. If
 we have `newtype List a = MkList [a]`, then we might want `Coercible
 (StateT Int [] a) (StateT Int List a)`, which would lead to `Coercible []
 List`, but that's ill-kinded! I think the first coercion is quite
 legitimate, and so we should find some way of allowing it. Generalizing
 `Coercible` seems to be the obvious way forward, but other possibilities
 are out there, I suppose.

 This problem (with `Coercible` being mono-kinded) came up in practice as a
 core-lint failure when compiling the libraries in my branch.

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