[GHC] #11732: Deriving Generic1 interacts poorly with TypeInType
GHC
ghc-devs at haskell.org
Mon Mar 21 17:01:57 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 goldfire):
No instantiation check. But what GHC does right now is, for every class in
a datatype's `deriving` clause, drop as many type parameters as there are
arguments to the class being derived. For example
{{{
data Foo a deriving (Show, Functor)
}}}
GHC knows that we mean `instance Show (Foo a)` and `instance Functor Foo`.
But
{{{
data Proxy k (a :: k) deriving Functor
}}}
would try `instance Functor (Proxy k)`, which is ill-kinded. GHC is surely
clever enough to figure out that it should really do `instance Functor
(Proxy *)`, but I think it should refrain from doing this.
More to the point of this ticket: I have a bad feeling my fix for #11357
is utterly broken, in that it uses the `tc_args` from the instance tycon
despite using visibilities from the parent tycon. Of course, the `tc_args`
don't match up. I suppose a `mkFamilyTyConApp` would work nicely here.
But you seem to know much more about generics in GHC than I do. Do you
think you could make this fix? I really do think we just need to use
`mkFamilyTyConApp` in the right spot here.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11732#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list