
#13324: Allow PartialTypeSignatures in the instance context of a standalone deriving declaration -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10607 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): We should make sure to watch out for these two corner cases: * Exotic constraints. Currently, trying to derive `Eq` like this: {{{#!hs newtype Foo f a = Foo (f (f a)) deriving Eq }}} Will be rejected with an error message saying: {{{ • No instance for (Eq (f (f a))) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself }}} That is, GHC will not put `Eq (f (f a))` into the set of inferred constraints because it is too "exotic". But presumably, we want a similar failure if the user instead typed this: {{{#!hs newtype Foo f a = Foo (f (f a)) deriving instance _ => Eq (Foo f a) }}} Since it's morally equivalent to just using a `deriving Eq` clause. * GADTs. GHC chooses not to even make an attempt if you try to stock- derive certain instances for GADTs with a `deriving` clause. For instance, this: {{{#!hs data T a where MkT :: T Int deriving Eq }}} is rejected with: {{{ • Can't make a derived instance of ‘Eq (T a)’: Constructor ‘MkT’ has existentials or constraints in its type Possible fix: use a standalone deriving declaration instead • In the data declaration for ‘T’ }}} So as a consequence, we should probably disallow this as well: {{{#!hs data T a where MkT :: T Int deriving instance _ => Eq (T a) }}} Notice that in both cases, the error message suggests trying a standalone deriving declaration! Obviously, we shouldn't do that if a user tries the equivalent, standalone approach with wildcards, so we should come up with a more appropriate error message for this scenario. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13324#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler