[GHC] #3097: Parser doesn't support doc comments on type aliases

GHC trac at galois.com
Tue Mar 31 03:42:56 EDT 2009


#3097: Parser doesn't support doc comments on type aliases
---------------------------------+------------------------------------------
    Reporter:  waern             |        Owner:                  
        Type:  bug               |       Status:  new             
    Priority:  normal            |    Milestone:                  
   Component:  Compiler          |      Version:  6.11            
    Severity:  major             |   Resolution:                  
    Keywords:  Haddock           |   Difficulty:  Unknown         
    Testcase:                    |           Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |  
---------------------------------+------------------------------------------
Comment (by simonpj):

 I think it'd be fine to accept the examples you give.  Doing so is in line
 with the principle I mentioned above. Indeed, rejecting them is probably
 accidental!

 Please write comments in your patch to explain why ctype and ctypedoc are
 distinct, notably the ambiguity in records.  Give an example of an
 ambiguous piece of program text!

 Just to explain why (x::ty) and (ty1~ty2) are accepted in ctype, when the
 parser sees
 {{{
  (C a, D a, a~b, x::Int) => blah
 }}}
 it can't tell that is is parsing a context, rather than a tuple, until
 very late.  So we pretend that it is parsing a tuple, and sort it out
 later. To make that work, the parser has to recognise `(C a, D a, a~b,
 x::Int)` as a tuple type.  And that in turn means recognising `(a~b)` and
 `(x::Int)` as a type.

 Lastly, you'll see that `(a~b)` and `(x::Int)` are treated differently
 (the former is in `context` while the latter is only in `type`).  The
 reason for this is, I think, that we want to allow `f` and `g2` but not
 `g1`:
 {{{
   f  :: a~F b => blah      -- Yes
   g1 :: x::Int => blah     -- No
   g2 :: (x::Int) => blah   -- Yes
 }}}
 I'm not quite sure why!

 While I was looking at the code, I noticed the following:
  * I don't think it's deliberate that `ctype` doesn't allow nested
 foralls, just like `ctypedoc`.  That is, it should probably say
 {{{
         | context '=>' ctype  { LL $ mkImplicitHsForAllTy   $1 $3 }
 }}}
  * We should probably use `gentype` rather than `type` in the LHS of type
 declarations
  * That would leave the only use of `type` in `ctype`; and only one of its
 occurrences makes sense there too!
  * So it might make sense to inline `type` there:
 {{{
 ctype  :: { LHsType RdrName }
         : 'forall' tv_bndrs '.' ctype   { LL $ mkExplicitHsForAllTy $2
 (noLoc []) $4 }
         | context '=>' ctype            { LL $ mkImplicitHsForAllTy   $1
 $3 }
         | ipvar '::' gentype
         | gentype                               { $1 }
 }}}
  * Which in turn would let us rename `gentype` to `type`

 I don't know if you feel like doing this, but I thought I'd record it here
 so I don't forget.

 Simon

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3097#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the Glasgow-haskell-bugs mailing list