[GHC] #11028: Refactor ConDecl

[GHC]

#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