Have a way to supersede grammar rules

[masak]

This comment:

There needs to be a way to displace/supersede grammar rules -- probably something with exactly the same category and declarative prefix as an existing rule needs to have an is replacing trait (possibly which even identifies the name of the old rule), otherwise the declaration is considered a compile-time conflict.

I'm thinking it'd also make sense to conservatively forbid an already displacing rule to be displaced by another rule... In the future when we understand the dynamics better, we might relax that.

[masak]

There's a weird interplay here between the lexical declaration (which is, for example, what figures during the export to another module) and the parser rule installation... for one, it would seem that if you import the lexical thing into another module, then the parser rule displacement also happens again, with that importing module's parser.

I mean, that's great news, but it's also pretty mind-blowing. For example, the conservative restriction about not displacing a displaced rule needs to happen also during that second displacement. All I can say is the compiler error for that one better be stellar. :star: It involves between two and four different code sites (the two displacements, and possibly imports for both of them).

[masak]

It would be especially impressive if we could re-use the notion of defer inside the is parsed of the displacing rule, so that a rule that wanted to displace-but-reuse could do that. This use of defer would likely have a completely different mechanism as it'd (a) be a rule of sorts and (b) happen inside of a regex... but still, it would be strangely consistent.

[masak]

Quick note as I'm re-reading this issue: maybe it makes sense to also have a mechanism to suppress the introduction of a new parser rule/alternation in the current module. My feeling is that in most modules with grammar extensions, it'd be fine to also (uselessly) extend that module's current grammar. But in some other cases, it might be annoying or harmful or impossible.

(Just one such example off the top of my head: we might have already used up our displacement of some rule, maybe through an import. We want to export another displacement, but we don't want to displace again in the current module because then we get an error.)

Interestingly, this would be expressed as an annotation (name bikeshedding left as an exercise to the reader) on the definition of the macro, not on the defined macro.