#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): Simon PJ's response: Ah, life is never as simple as you hope. The whole treatment of recursive types is a bit flaky in GHC. For newtypes here is the motivation {{{ newtype R = MkR R }}} Now if we have an instance {{{ instance Coercible a R => Coercible a R }}} we aren't going to make much progress. Mutual recursion is similar. This is very much a corner case. I think that if the recursion is under a type constructor eg {{{ newtype R1 = MkR [R1] }}} then we are fine. But the current test is conservative. I worry about {{{ newtype R2 a = MkR (F a) }}} because perhaps {{{ type instance F Int = R2 Int }}} and now `R2 Int` is just like `R`. But GHC won't spot this today. In any case, I suppose that, provided it was documented, GND could simply ignore the recursion problem, behave as advertised, and if that gives a loop it's the programmer's fault. Things in hs-boot files are treated (again conservatively) as if they might be recursive. A related thing is unpacking data types. Consider {{{ data T = MkT {-# UNPACK #-} !S data S = MkS {-# UNPAXCK #-} !Int {-# UNPAXCK #-} !Int }}} A `S`-value is represented as a pair of `Int#` values. And similarly `T`. But what about {{{ data S2 = MkS2 {-# UNPACK #-} !Int {-# UNPACK #-} !S2 }}} We don’t want to unpack infinitely. Strictness analysis also risks infinitely unpacking a strict argument. I think the rules for newtypes could be different (and perhaps more generous) than for data types. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8503#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler