| Cross-references with ambiguous use of period '.' [message #802796] |
Mon, 20 February 2012 08:05  |
Eclipse User |
|
|
|
My DSL uses the period '.' in a somewhat ambiguous way, both for module qualification and for record projection, i.e.:
1. Common.makeNoun - a function in an external module
2. person.name - a record field
In the grammar, these are handled by the same rule as below. Trying to have different rules would just introduce ambiguity to the grammar and prevent it from compiling.
Exp : name=[Ident] '.' label=Ident
But this causes a problem for resolving cross-references; in the case of qualification I want to be able to resolve the label, but in the case of projection I don't want this to be a cross-reference.
To me, the best solution seems to be making all labels cross-refs as follows:
Exp : name=[Ident] '.' label=[Ident]
and then inside my ScopeProvider, performing some sort of check such that if it is a case of projection, then the scope is trivially resolved to itself. However this doesn't feel very elegant.
Any ideas of a better way of handling this?
|
|
|
|
|
| Re: Cross-references with ambiguous use of period '.' [message #804176 is a reply to message #803515] |
Wed, 22 February 2012 04:37  |
| Eclipse User |
|
|
|
Thanks for your reply Meinte!
The ambiguity is more of a semantic one than a grammatical one; if the name of Exp is found to be a valid module name then label should be a cross-reference to an identifier defined that module. But if name is a local variable then label should not be treated as a cross-reference at all. This may sound strange, but essentially it is because I am intentionally avoiding type-checking of local variables.
The solution I went for works this way:
1. Both segments of Exp are treated as cross-refs in the grammar, i.e.: Exp : name=[Ident] '.' label=[Ident]
2. Overriding DefaultLinkingService#getLinkedObjects, I check whether the condition as described above is met.
3. If it is determined that label should not be a cross-reference, then I trivially satisfy it by creating a matching EObject in a dummy resource and linking it to that.
4. As described in this thread, I also override LazyLinker#beforeModelLinked and delete the dummy resource to clean these dummy EObjects.
So far this solution seems adequate, although I will post more updates here if any new issues or improvements arise.
|
|
|
Powered by
FUDForum. Page generated in 0.03242 seconds
Home