#14529: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: 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): The problem with `LHsQTyVars` is that every other instance of that type stores the user-written tyvars of a tycon declaration. Thus, the `kcHsTyVarBndrs` function that checks them asks for information about CUSKs, etc., which is utterly wrong for data constructors. (The reason I refactored this is that I've had to make some changes to `kcHsTyVarBndrs` in my type-level implication constraints patch, such that it no longer works at all for datacons.) Really, the right type for GADT constructors is `HsImplicitBndrs`. The problem is that you'd then have to have a tiered structure, where a `ConDeclGADT` stores an `HsImplicitBndrs` wrapped around a `ConDeclGADTDetails` or some such. It's a bit ugly. But the structure would be just right. Alternatives would be to have a `con_implicit_qvars :: [IdP pass], con_explicit_qvars :: [LHsTyVarBndr pass]`, or a new function to consume a `LHsQTyVars` from a datacon (instead of `kcHsTyVarBndrs`). Also, why change the `Maybe ...` to a `Bool` (with an invariant) to say whether or not there's a forall? The `Maybe` seems closer to the truth. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14529#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler