Widen the range of applications for Cross-References

[danieldietrich]

With the new colon ':' syntax, Cross-References already look like rules. Why not treat a Cross-Reference as "inline rules" (that return a type)?

In the case of a Cross-Reference identifier=[type:token] I suggest to allow rule references and inline rules in place of token.

Examples:

// rule reference
Rule: func=[AbstractFunc: SomeRule] ;
SomeRule: ... ;

// rule alternatives
Rule: func=[AbstractFunc: Rule1 | Rule2] ;
Rule1: ... ;
Rule2: ... ;

// token
Rule: func=[AbstractFunc: TOKEN] ;
TOKEN: ... ;

Question / offtopic: Would it make sense to allow named references (here: SomeRule.name)?

// rule reference
Rule: func=[AbstractFunc: SomeRule.name] ; // SomeRule.name evaluates to ID
SomeRule: name=ID ;

[pluralia]

I like the idea (especially for alternatives), but can't catch a role of AbstractFunc. Could you explain how is it used?

How I understand, proposed syntax for rule alternatives replaces such things:

Rule: func=[AbstractFunc] ;
AbstractFunc: Rule1 | Rule2

where AbstractFunc is a dummy rule that exists only to "union" Rule1 and Rule2 and create a cross-reference. However, when we allow alternatives inside a cross-reference, we can write it directly without AbstractFunc:

Rule: func=[Rule1 | Rule2] ;

[spoenemann]

I suggest to allow rule references

That's already possible. But we restrict this to data type rules, i.e. parser rules that evaluate to a single primitive value (usually a string) instead of an object. IMO using an object-typed rule wouldn't make sense, as here we're interested only in the the name of our reference target, not its full definition (which may be arbitrarily complex with many nested objects).

and inline rules

We already have a form of "inline rules": Actions. But again, we only look at how to parse the name of our reference target, not the whole object subtree. I don't see much benefit in declaring a data type rule inline, but I may be convinced with an example showing how it can improve readability or other aspects of the grammar.

Would it make sense to allow named references

In principle, yes. Our default behavior is to resolve the name property of our reference target. However, the way how we currently offer to customize that is through the NameProvider service, so we offer maximum flexibility to compute the name from other properties. It would be hard to capture the same flexibility in the grammar language itself.

I propose to close this issue and reopen in case we want to revive the ideas of widening the cross-reference syntax.