running out of bits in lexer

[Simon Peyton-Jones]

yes I think that sounds like a good plan. It would be good to document it with 
a careful Note in Parser.y.pp, cross-referenced from the relevant places in Lexer.x.

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Richard
|  Eisenberg
|  Sent: 12 September 2013 04:54
|  To: GHC Devs
|  Subject: running out of bits in lexer
|  
|  Hi devs,
|  
|  I'm in the process of reimplementing role annotations (#8185). I need to add a
|  new pseudo-keyword 'role' to the lexer, and I'm initially tempted to guard the
|  lexing of this keyword with an extension bit (like, say, tyFamBit in Lexer.x). But,
|  there are already bits 0 to 31 taken, and the type of the bitmap is Int, so I'm out
|  of luck.
|  
|  However, I think there's a way out: the parser should do the right thing when it
|  sees these pseudo-keywords, and hopefully the downstream code could check the
|  enabled options. So, it would seem that having some of these bit controls in the
|  lexer is unnecessary -- more a belt-and-suspenders thing than anything else.
|  
|  So, I propose to let the lexer treat 'role' specially in all cases, relying on the parser
|  to treat it like an ordinary varid except when 'role' comes right after 'type'.
|  
|  Is there something I'm missing here? In particular, I can't think of a good reason
|  not to treat the pseudo-keyword 'family' in the same way and allow it to lex
|  regardless of the extensions. This might also improve error messages.
|  
|  Thanks,
|  Richard
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  http://www.haskell.org/mailman/listinfo/ghc-devs