[GHC] #11732: Deriving Generic1 interacts poorly with TypeInType

GHC ghc-devs at haskell.org
Mon Mar 21 16:02:30 UTC 2016


#11732: Deriving Generic1 interacts poorly with TypeInType
-------------------------------------+-------------------------------------
        Reporter:  goldfire          |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.1
      Resolution:                    |             Keywords:  TypeInType,
                                     |  Generics
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by RyanGlScott):

 Replying to [https://ghc.haskell.org/trac/ghc/ticket/11357#comment:13
 goldfire]:
 > I'm frankly unsure (without more research) as to what the desired
 behavior should be here.

 The reason for this restriction dates back to #5939, when someone wanted
 to try to standalone derive this:

 {{{#!hs
 data T a = T a
 deriving instance Generic (T Bool)
 }}}

 This seems intuitive, but
 [https://ghc.haskell.org/trac/ghc/ticket/5939#comment:1 Pedro couldn't
 find a way to make it work], since the generated `Rep` type only uses
 information from `T`'s `TyCon`, so there was no good way to relate the
 `TyVar` `a` with `Bool`. He then declared that
 [https://ghc.haskell.org/trac/ghc/ticket/5939#comment:2 such instances
 should be rejected altogether], hence this instantiation check.

 Whether the instantiation check is a good idea (and ways to get around it)
 are a side issue, I feel like. The real issue is that data family
 instances classify their types as visible/invisible in a completely
 different manner than vanilla datatypes. I did a bit of digging into the
 `ProxyFam` example above. With this:

 {{{#!hs
 data Proxy k (a :: k) = ProxyCon deriving Generic1
 }}}

 [http://git.haskell.org/ghc.git/blob/c37a583fb9059053f83f1ab0c3cb7eb7047b1a31:/compiler/types/Type.hs#l1456
 partitionInvisibles user_tc id tc_args] yields `([],[*])`, like you'd
 expect (where `k` has been instantiated to `*` due to `Generic1` being of
 kind `(* -> *) -> Constraint`). But with this:

 {{{#!hs
 data family ProxyFam (a :: y) (b :: z)
 data instance ProxyFam k (a :: k) = ProxyFamCon deriving Generic1
 }}}

 [http://git.haskell.org/ghc.git/blob/c37a583fb9059053f83f1ab0c3cb7eb7047b1a31:/compiler/types/Type.hs#l1456
 partitionInvisibles user_tc id tc_args] yields `([*],[])`! Somehow, `k` is
 being treated as invisible when it clearly shouldn't. It's beyond my pay
 grade to speculate on //why// that is, but it's definitely
 [https://ghc.haskell.org/trac/ghc/ticket/11376#comment:12 not the only]
 `-XTypeInType`-related data family discrepancy.

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


More information about the ghc-tickets mailing list