Opened 8 years ago

Closed 7 years ago

Last modified 4 years ago

#5939 closed bug (fixed)

Standalone deriving Generic on type with instantiated arguments

Reported by: dreixel Owned by: dreixel
Priority: normal Milestone:
Component: Compiler Version: 7.5
Keywords: Generics Cc: reiner.pope@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: GenCannotDoRep0
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


Reiner Pope reports that the following code

{-# LANGUAGE DeriveGeneric, FlexibleInstances, StandaloneDeriving #-}
import GHC.Generics
data T a = T a
deriving instance Generic (T Bool)

generates the following:

instance Generic (T Bool) where ...
type instance Rep (T a) = ...

This is wrong. The type instance should probably be for Rep (T Bool). Or perhaps we should refuse to derive Generic for instantiated types altogether.

Change History (7)

comment:1 Changed 8 years ago by dreixel


This is actually a bit harder than I thought. Right now the representation type is generated only from the tycon of T. I can get the instantiated type (T Bool) from the ds_tys field of the DerivSpec at genInst, but I'm not sure how I can relate the type variables to the instantiated types. For instance:

data T a b c = T a b c
deriving instance Generic (T a Bool c)

The representation should look something like:

type instance Rep (T a Bool c) = a :*: Bool :*: c

But since the function that generates the representation (tc_mkRepTy) only takes the tycon of T, it won't know that b has been instantiated to Bool. Even if I pass it the full instantiated type T a Bool c, how can I easily relate the tycon's variables to their instantiated types?

comment:2 Changed 8 years ago by dreixel

Actually I now think we should reject these altogether, because I cannot see a reasonable use case for it (unless the datatype is a data family). If no one objects, I'll treat the current behaviour as a bug and add a check that will prevent deriving Generic on types with instantiated arguments.

comment:3 Changed 8 years ago by reinerp

This sounds fine by me, as long as it still works for data families.

comment:4 Changed 7 years ago by jpm@…

commit 156ec95a8e92cc8314db134311d2fbb0269f0679

Author: Jose Pedro Magalhaes <>
Date:   Thu Jun 21 12:23:01 2012 +0100

    Allow deriving Generic1
    This completes the support for generic programming introduced
    in GHC 7.2. Generic1 allows defining generic functions that
    operate on type containers, such as `fmap`, for instance.
    Along the way we have fixed #5936 and #5939, allowing
    deriving Generic/Generic1 for data families, and disallowing
    deriving Generic/Generic1 for instantiated types.
    Most of this patch is Nicolas Frisby's work.

 compiler/basicTypes/OccName.lhs      |    5 +-
 compiler/prelude/PrelNames.lhs       |   13 +-
 compiler/typecheck/TcDeriv.lhs       |  158 +++++++----
 compiler/typecheck/TcGenGenerics.lhs |  514 ++++++++++++++++++++++++++--------
 4 files changed, 521 insertions(+), 169 deletions(-)

comment:5 Changed 7 years ago by dreixel

Resolution: fixed
Status: newclosed
Test Case: GenCannotDoRep0


comment:6 Changed 4 years ago by RyanGlScott

Keywords: Generics added

comment:7 Changed 4 years ago by Ben Gamari <ben@…>

In 7443e5c8/ghc:

Remove the instantiation check when deriving Generic(1)

Previously, deriving `Generic(1)` bailed out when attempting to
instantiate visible type parameters (#5939), but this instantiation
check was quite fragile and doesn't interact well with `-XTypeInType`.
It has been decided that `Generic(1)` shouldn't be subjected to this
check anyway, so it has been removed, and `gen_Generic_binds`'s
machinery has been updated to substitute the type variables in a
generated `Rep`/`Rep1` instance with the user-supplied type arguments.

In addition, this also refactors `Condition` in `TcDeriv` a bit. Namely,
since we no longer need `tc_args` to check any conditions, the `[Type]`
component of `Condition` has been removed.

Fixes #11732.

Test Plan: ./validate

Reviewers: goldfire, kosmikus, simonpj, bgamari, austin

Reviewed By: simonpj, bgamari

Subscribers: thomie

Differential Revision:

GHC Trac Issues: #5939, #11732
Note: See TracTickets for help on using tickets.