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@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@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs