Factor: Unary ({FactorOp.left=current} dotOp=("." | "*.") ("[" index=Expr? (range?='to' rangeEnd=Expr)? "]" | member=Name))*;

The problem is that the class generated for this (FactorOp) infers that the type of FactorOp.left will be Unary whereas it may be Unary or another FactorOp if these are chained.

How can I tell Xtext to declare the type of FactorOp.left as Factor or some other common base class of Unary and Factor?

]]>

ImpliesCondition: LogicalOr ({BinaryOp.left=current} =>op=('implies' | '\\implies') right=LogicalOr )*;

The resulting class "BinaryOp" has both left and right with type "LogicalOr" which means it cannot be recursive and have an ImpliesCondition on the left.

For the binary operators I think I can workaround it by using rules like:

ImpliesCondition: LogicalOr ({BinaryOp.left=current} =>op=('implies' | '\\implies') right=ImpliesCondition)?;

But I'm still pondering how to do that for my "Factor" rule above, and I'm not sure these rules should really be right-associative.

]]>

http colon //blog.efftinge.de/2010/08/parsing-expressions-with-xtext.html

The Online Help doesn't seem to have any examples of left-associative operators at the moment.

]]>

Turns out not so much a case of RTFM but check out the examples ...

I need to put "returns Expr" for all of the related rules, then it'll use Expr as the field type and clean up the type hierarchy.

]]>