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

 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