#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