#14332: Deriving clauses can have forall types -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj):
I intended to move the forall to the left of the context.
Aha, that makes a huge difference. I thought you were advocating generating a derived instance like {{{ instance ... => C (forall k. T k a) where ... }}} which would be bad. (We don't allow that in source code, so we shouldn't in deriving-generated code.) But if you mean just moving the foralls to the left, then we've supported that for ages in the abstract syntax {{{ data HsDerivingClause pass -- See Note [Deriving strategies] in TcDeriv = HsDerivingClause { deriv_clause_strategy :: Maybe (Located DerivStrategy) -- ^ The user-specified strategy (if any) to use when deriving -- 'deriv_clause_tys'. , deriv_clause_tys :: Located [LHsSigType pass] -- ^ The types to derive. -- -- It uses 'LHsSigType's because, with @-XGeneralizedNewtypeDeriving@, -- we can mention type variables that aren't bound by the datatype, e.g. -- -- > data T b = ... deriving (C [a]) -- -- should produce a derived instance for @C [a] (T b)@. } }}} Note the `LHsSigType` and comment. I'm not saying it's implemented right, and it appears to be undocumented in the user manual, but it's there by design. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14332#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler