Problem statement
Hello, I'm trying to parse a language similar to a tiny subset of Java.
I only need to parse expressions that can apply functions and use the logical and numerical comparison operators, and math operations.
I'm having trouble with precedence, read all the docs (even took the basic math part from there) but couldn't figure it out yet.
What was tried and examples
However, I already started using precedence with "value_comparison_op.1", "bool_comparison_op.2" to force priority, but to no avail. Worse, if I use identifiers that access members of the classes I get a different interpretation of the same basic form.
Below are two examples, but my objective first:
Input: a == u or b == v
Desired: (a == u) or (b == v)
However it is interpreting as a == (u or (b==v))
And if I add member access (nested identifier), it's even more broken. See the 2 examples below:

Here's the relevant part (I believe):
rule: expression
?expression: value
| sum
| funcall
| "(" expression ")"
| coallesce
| logical_expression
| comment
logical_expression: comparison
| negation
comparison: bool_comparison
?bool_comparison: value_comparison
| expression bool_comparison_op expression
?value_comparison: expression value_comparison_op expression
negation: "!" expression
value_comparison_op: EQ
| NEQ
| GE
| LE
| GT
| LT
bool_comparison_op: or | and
I think all the code is suffering from such problems, including funcall's method name before the parenthesis, being identified as an identifier and not a function call and its arglist.
Thanks!
The general idea is to clearly define the tree structure you want to have at the end. If you want this:
and_expression:
comparison:
sum:
number
number
...
you 'just' have to clearly tell the parser which rules are 'below' which other ones:
?and_expression: [and_expression "and"] comparison
?comparison: [sum value_comparison_op] sum
?sum: [sum "+"] number
I would suggest looking at the calculator example for more examples.
Thanks so much @MegaIng !
I think it now makes more sense to me :)
I think how you explained is simpler and more logical by applying left recursion over and over directly :)
Will try that :)
Echoing the above comment, I found this chapter of Crafting Interpreters to be very helpful.
Most helpful comment
The general idea is to clearly define the tree structure you want to have at the end. If you want this:
you 'just' have to clearly tell the parser which rules are 'below' which other ones:
I would suggest looking at the calculator example for more examples.