Parser: The BitMap of reservedWordsFM doesn't work well with extension suggestions.

While figuring out Or patterns with @knothed, we added a new contextual keyword one (as in the Or pattern (one of LT, EQ)). The natural choice was to add the following entry to reservedWordsFM in the Lexer:

+         ( "one",            ITone,           xbit OrPatternsBit),

Note the usage of xbit instead of merely 0. The latter would indicate that this keyword is always active.

Alas, although that fixes rejecting one as an identifier when -XOrPatterns is not active, it also regresses in usability, because now when the user writes an Or pattern, she no longer sees the suggestion to enable -XOrPatterns!

So what David did (in !9229 (closed)) was to have

+         ( "one",            ITone,           0),

and add a production to special_id in the Parser:

special_id
        : ...
        | 'prim'                { sL1 $1 (fsLit "prim") }
+        | 'one'                 { sL1 $1 (fsLit "one") }
        | 'javascript'          { sL1 $1 (fsLit "javascript") }
        ...

Now we get good suggestions and won't gobble up one (unless it's in a pattern and followed by the keyword of).

I think Note [Lexing type pseudo-keywords] argues similarly for keywords such as role, family etc. Strangely, it adds the production to varid directly instead of special_ids, where it would fit better, IMO. Doesn't matter much though.

Proposal

We should

1. Identify extension keywords that can benefit from this procedure, which is:

   Pretend that the extension is enabled and fall back to a special_id production if the parse of the extended syntax was unsuccessful. Otherwise reject and suggest to enable the extension

   As an example, I recall that the suggestion for pattern synonyms does not work ATM. Perhaps we could make it work.

2. In the unlikely event that all xbit can be removed from reservedWordsFM, simplify.

3. Document the procedure above and how to judge whether it applies to Your Extension

4. Move the type pseudo-keywords to special_ids productions

CC @int-index who seems to have worked on this in the past.