#8950: Typeable instances for promoted lists and tuples -------------------------------------+------------------------------------ Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.1-rc2 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): What's the desired behavior here? There are several cases to consider: 1. No `AutoDeriveTypeable`, no `DataKinds`, `deriving` clause on a promotable datatype 2. No `AutoDeriveTypeable`, no `DataKinds`, standalone deriving on a promotable datatype 3. No `AutoDeriveTypeable`, yes `DataKinds`, `deriving` clause on a promotable dataype 4. No `AutoDeriveTypeable`, yes `DataKinds`, standalone deriving on a promotable datatype 5. Yes `AutoDeriveTypeable`, no `DataKinds`, no explicit `deriving` 6. Yes `AutoDeriveTypeable`, yes `DataKinds`, no explicit `deriving` 7. Yes `AutoDeriveTypeable`, no `DataKinds`, explicit `deriving` somewhere 8. Yes `AutoDeriveTypeable`, yes `DataKinds`, explicit `deriving` somewhere Currently, 1, 2, and 5 do their thing for the unpromoted datatype. 3, 4, and 6 work for both the unpromoted and the promoted datatypes. Curiously, 7 & 8 don't work! That is, if you say {{{ {-# LANGUAGE AutoDeriveTypeable #-} data Foo = Bar deriving (Eq) }}} you '''don't''' get `Typeable` instances. This seems to be a bug. It seems to be trying to prevent duplicate instances, but any `deriving` clause (even standalone) triggers the filter. (See around line 550 of !TcDeriv.) I propose: all 8 derive for both the promoted and unpromoted datatype. I can't see a downside to too many `Typeable` instances. Thoughts? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8950#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler