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) 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
-
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 extensionAs an example, I recall that the suggestion for pattern synonyms does not work ATM. Perhaps we could make it work.
-
In the unlikely event that all
xbit
can be removed fromreservedWordsFM
, simplify. -
Document the procedure above and how to judge whether it applies to Your Extension
-
Move the type pseudo-keywords to
special_ids
productions
CC @int-index who seems to have worked on this in the past.