#11028: Refactor ConDecl -------------------------------------+------------------------------------- Reporter: simonpj | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: | -------------------------------------+------------------------------------- Old description:
The `ConDecl` type in `HsDecls` is an uneasy compromise. For the most part, `HsSyn` directly reflects the syntax written by the programmer; and that gives just the right "pegs" on which to hang Alan's [wiki:ApiAnnotations API annotations]. But `ConDecl` doesn't properly reflect the syntax of Haskell-98 and GADT-style data type declarations.
To be concrete, here's a draft new data type {{{ data ConDecl name | ConDeclGADT { con_names :: [Located name] , con_type :: LHsSigType name -- The type after the ‘::’ , con_doc :: Maybe LHsDocString }
| ConDeclH98 { con_name :: Located name
, con_implict :: HsImplicitBndrs () -- ^ Implicit binders, added by renamer
, con_qvars :: Maybe [LHsTyVarBndr name] -- User-written foralls (if any)
, con_cxt :: Maybe (LHsContext name) -- ^ User-written context (if any)
, con_details :: HsConDeclDetails name -- ^ Arguments
, con_doc :: Maybe LHsDocString -- ^ A possible Haddock comment. } deriving (Typeable) }}} Note that * For GADTs, just keep a type. That's what the user writes. (NB: `HsType` can represent records on the LHS of an arrow: `{ x:Int,y:Bool } -> T`
* `con_qvars` and `con_cxt` are both `Maybe` because they are both optional (the `forall` and the context of an existential data type)
This ticket is just to track the thought and invite feedback.
New description: The `ConDecl` type in `HsDecls` is an uneasy compromise. For the most part, `HsSyn` directly reflects the syntax written by the programmer; and that gives just the right "pegs" on which to hang Alan's [wiki:ApiAnnotations API annotations]. But `ConDecl` doesn't properly reflect the syntax of Haskell-98 and GADT-style data type declarations. To be concrete, here's a draft new data type {{{ data ConDecl name | ConDeclGADT { con_names :: [Located name] , con_type :: LHsSigType name -- The type after the ‘::’ , con_doc :: Maybe LHsDocString } | ConDeclH98 { con_name :: Located name , con_qvars :: Maybe (LHsQTyVars name) -- User-written forall (if any), and its implicit -- kind variables -- Non-Nothing needs -XExistentialQuantification , con_cxt :: Maybe (LHsContext name) -- ^ User-written context (if any) , con_details :: HsConDeclDetails name -- ^ Arguments , con_doc :: Maybe LHsDocString -- ^ A possible Haddock comment. } deriving (Typeable) }}} Note that * For GADTs, just keep a type. That's what the user writes. (NB: `HsType` can represent records on the LHS of an arrow: `{ x:Int,y:Bool } -> T` * `con_qvars` and `con_cxt` are both `Maybe` because they are both optional (the `forall` and the context of an existential data type * For `ConDeclGADT` the type variables of the data type do ''not'' scope over the `con_type`; whereas for `ConDeclH98` they ''do'' scope over `con_cxt` and `con_details`. This ticket is just to track the thought and invite feedback. -- Comment (by simonpj): PS: I have edited the proposed data type a bit. Do you agree with it? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11028#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler