Makes sense, I just read too much into "Associativity is always left when
> left recursing".
>
I should probably check the wording I used in the documentation…
I tend to disagree that it's not worthwhile and changing the grammar is the
> right solution.
>
I did change the grammar to solve associativity in a particular case,
because I thought that solved most cases for which left recursion was
wanted. The problem was How to designate which is the operator in right
hand side?
TatSu has closures with separators. The expression:
op.{ e }+
Is equivalent to:
e { op ~ e }
Where “~” is the cut operator. As it was, the tree for the expression is a
flat list of` e,e,e... so I added left and right associative versions
op.>{ e }+
op.<{ e }+
Those expressions produce left and right trees respectively.
My quest for a *reasonable* PEG+LEFT (like yours) had two purposes:
- It was the natural way to indicate left associativity in practical
cases.
- When Grako (before TatSu) was used for teaching, *reasonable* support
for left recursion was expected, even when the problem was not solved for
PEG.
This being said, newer version of my tool eschew perform this by
> "rewriting" (not really but I don't want to get into the specifics) a
> right-associative parse tree into a left-associative one if required. So
> left-associativity is still available, but does not need to be encoded in
> the parser anymore.
>
The above expressions also rewrite the list into the expected left/right
tree.
I don’t know if it’s worth it to add notation for specifying lef/right
associative rules. All parts of the TatSu (previously Grako) syntax have
come from the practical needs in my work.
At the moment, now that left recursion is working, I should probably write
a few test cases to check what expressions like this mean:
e = ('+'|'-').{ e }+ | int ;
--
Juancarlo *Añez*
_______________________________________________
PEG mailing list
PEG@lists.csail.mit.edu
https://lists.csail.mit.edu/mailman/listinfo/peg
