chanicpanic

I have it down to: ```python grammar = """ start: (a+)* !a.1: "A" | """ l = Lark(grammar) tree = l.parse("A") print(tree.pretty()) ``` Output: ``` start a a A a...

The issue is that when `ambiguity="resolve"`, the `ParseTreeBuilder` will use the `ChildFilterLALR` filters. However, the `ForestToParseTree` cache breaks the `ChildFilterLALR` assumption that it is safe to change the parse tree....

The `ForestToParseTree` cache and `ChildFilterLALR` filter are both optimizations that happen to be incompatible with each other. So, the question is: which optimization gives the most performance benefit for earley...

> I think it's best to make an evidence-based choice, which makes me wonder, do you have an idea for what a good benchmark grammar&input for Earley would be? >...

The example provided is actually a special case that may be open to optimization. Consider the general case in which expansions of `field` may contain more than one rule: ```lark...

I agree that an array is correct given the current behavior. Although, I wouldn't make the change just yet because I believe the earley implementation can be adjusted so that...

@erezsh I believe that result is correct, although I can certainly understand why it may not appear so. The first `_ambig` node means that the first child of `start` may...

> I'm worried about it because changing the default order might cause errors for users who have accidental ambiguities in their grammar. So I want to make sure we're now...

All of the derivations are distinct. They just happen to produce identical trees after tree shaping. This is most easily seen with the `TreeForestTransformer`: ```python from lark import Lark from...