[GHC] #10996: family is treated as keyword in types even without TypeFamilies enabled

[GHC]

#10996: family is treated as keyword in types even without TypeFamilies enabled
-------------------------------------+-------------------------------------
        Reporter:  oerjan            |                Owner:
            Type:  bug               |               Status:  new
        Priority:  low               |            Milestone:
       Component:  Compiler          |              Version:  7.10.2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  GHC rejects       |            Test Case:  type Test
  valid program                      |  family = family
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 Indeed.  In `Parser.y` we see:
 {{{
 tyvarid :: { Located RdrName }
         : VARID            { sL1 $1 $! mkUnqual tvName (getVARID $1) }
         | special_id       { sL1 $1 $! mkUnqual tvName (unLoc $1) }
         | 'unsafe'         { sL1 $1 $! mkUnqual tvName (fsLit "unsafe") }
         | 'safe'           { sL1 $1 $! mkUnqual tvName (fsLit "safe") }
         | 'interruptible'  { sL1 $1 $! mkUnqual tvName (fsLit
 "interruptible") }

 varid :: { Located RdrName }
         : VARID            { sL1 $1 $! mkUnqual varName (getVARID $1) }
         | special_id       { sL1 $1 $! mkUnqual varName (unLoc $1) }
         | 'unsafe'         { sL1 $1 $! mkUnqual varName (fsLit "unsafe") }
         | 'safe'           { sL1 $1 $! mkUnqual varName (fsLit "safe") }
         | 'interruptible'  { sL1 $1 $! mkUnqual varName (fsLit
 "interruptible")}
         | 'forall'         { sL1 $1 $! mkUnqual varName (fsLit "forall") }
         | 'family'         { sL1 $1 $! mkUnqual varName (fsLit "family") }
         | 'role'           { sL1 $1 $! mkUnqual varName (fsLit "role") }

 -- These special_ids are treated as keywords in various places,
 -- but as ordinary ids elsewhere.   'special_id' collects all these
 -- except 'unsafe', 'interruptible', 'forall', 'family', and 'role',
 -- whose treatment differs depending on context
 special_id :: { Located FastString }
 special_id
         : 'as'                  { sL1 $1 (fsLit "as") }
         | 'qualified'           { sL1 $1 (fsLit "qualified") }
         | 'hiding'              { sL1 $1 (fsLit "hiding") }
         | 'export'              { sL1 $1 (fsLit "export") }
         | 'label'               { sL1 $1 (fsLit "label")  }
         | 'dynamic'             { sL1 $1 (fsLit "dynamic") }
         | 'stdcall'             { sL1 $1 (fsLit "stdcall") }
         | 'ccall'               { sL1 $1 (fsLit "ccall") }
         | 'capi'                { sL1 $1 (fsLit "capi") }
         | 'prim'                { sL1 $1 (fsLit "prim") }
         | 'javascript'          { sL1 $1 (fsLit "javascript") }
         | 'group'               { sL1 $1 (fsLit "group") }
 }}}
 The idea of `special_id` is a good one, because it avoids stealing
 keywords.

 The comment claims that 'unsafe', 'safe', and 'interruptible' have
 treatment that varies by context; but that claim seems bogus.  The ONLY
 uses of `special_id` is the code above, so adding those three to
 `special_id` and removing them from `varid` and `tyvarid` should be a
 useful simplification.  Can someone try?

 'forall' is different because in ''terms'' it is not a keyword, but in
 ''types'' it is.  The lexer therefore only recognises it when specific
 flags are on.

 'role' and 'family' are the warts.  Can we put them in `special_id`?  I
 think (but I am not certain) that the reason they are not there is to
 exclude them from `tyvarid`.  Why do that?  I think (but I am not sure)
 that the reason is to resolve the ambiguity in comment:1.  If someone felt
 able to resolve that ambiguity some other way, it'd be great.  Otherwise
 this really is a bug.

 This isn't really hard, I think; just needs someone to to think clearly
 for a while.

 Thanks

 Simon

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