Allow qualified names as non-terminals to enable disambiguation of concrete patterns #2589
Description
A case in point
A "hole" in a concrete pattern is a position where typed pattern variables can be introduced. Suppose we want to write a concrete pattern for a Rascal module described as follows:
start syntax Module
= \default: Header header Body body ;
The pattern would look like this
(Module) `<Header header> <Body body>`
Typically this would occur in code like (focussing completely on body):
void collect((Module) `<Header header> <Body body>`, ...){
// do something with _body_
}
Everything looks fine and dandy until ... we import the module Content that declares the name Body as well:
alias Body = ...;
This invalidates the <Body body> in the concrete pattern above since Body is now ambiguous.
A first impulse is to write <lang::rascal::\syntax::Rascal::Body body> instead but that is not allowed by the current Rascal grammar.
The only available alternative is to rewrite the code into:
void collect(Module m, ...){
handleBody(m.body, ...)
}
void handleBody(lang::rascal::\syntax::Rascal::Body body, ...){
// do something with body
}
Key in this solution is that we can properly disambiguate the Body argument of handleBody.
Solution direction
Concrete holes are defined as follows in the Rascal grammar:
syntax ConcreteHole
= \one: "\<" Sym symbol Name name "\>"
;
where a Sym can be many things including a name (via Nonterminal).
We have a general mechanism for disambiguating names: prefixing a name with a qualifier which can either be a module name or a datatype name. We should apply that here as well.
Proposal
Allow a QualifiedName as aNonterminal.
Closing notes
- As shown above, rewriting the code such that
<Body body>is handled as function argument solves the issue since thereQualifiedNames are allowed. - This issue is a bit annoying but not highly urgent.
- The proposed change will, in all its simplicity, be rather invasive since it will touch many parts of the Rascal implementation.
- Main purpose of this issue is therefore to document this problem.