#14045: Data family instances must list all patterns of family, despite documentation's claims to the contrary -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T14045, | indexed-types/should_fail/T14045a Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Phab:D3804 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott):
Do you agree this is a bug?
I certainly do. In the bowels of `TcDeriv`, we check that `newTyConEtadRhs` (the eta-reduced representation type) can accommodate the number of arguments from the instance we're deriving. But after doing some `pprTrace` scavenging, I discovered that the `newTyConEtadRhs` for `newtype instance T Int :: Type -> Type` is {{{#!hs ([a_a1vc], IO a_a1vc) }}} Whereas for `newtype instance T Int a :: Type`, it's: {{{#!hs ([], IO) }}} Something fishy is going on. The result of `newTyConEtadRhs` is ultimately being created in `mkNewTyConRhs`, which computes the eta-reduced type variables by checking one-by-one if a tycon tyvar matches the tyvar in the representation type in the corresponding position (see [https://git.haskell.org/ghc.git/blob/c13720c8c6047844f659ad4ce684946b80c99be... eta_reduce]). My guess is that this `a_a1vc` tyvar from the representation type doesn't match the corresponding tyvar from `newtype instance T Int :: Type -> Type` (what //would// the corresponding tyvar be, anyway?) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14045#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler