Here what happens (it only happened in this case and I can't imagine why): the parser returns a parsing three containing a different phrase than what was given as input to the .parse method. Moreover there is an ambiguity in the input phrase and this isn't represented. I'm fairly sure the second thing is causing the first one.
I'm attaching a test to reproduce this behavior:
https://pastebin.com/yJW66hu6
Thanks for building this and thanks in advance if you take this issue into consideration.
I am not the maintainer, but here a bit of general advice to make it easy for everyone involved:
Thanks for you answer. You are right, I can be more clear. Sorry but this is the first time I submit an issue on GH.
I'm going to add more details:
When I parse the sentence:
"c'猫 probabilit脿 di nevicate domani"
I get the following parse tree:
start
weather_question
weather_question_int_13
question_snow
question_snow_int_53
motion_loc
motion_loc_int_1 c'猫
chance
chance_int_0
probabilit脿
di
query_snow
query_snow_int_4 nevicate
motion_loc
motion_loc_int_1 c'猫
chance
chance_int_0 probabilit脿
query_snow
query_snow_int_4
di
nevicate
future_point_in_time
future_point_in_time_int_0 domani
which would be correct if I parsed the sentence: "c'猫 probabilit脿 di nevicate c'猫 probabilit脿 di nevicate domani".
About the ambiguity:
chance_int_0 has the ability to match "probabilit脿 di";
query_snow_int_4 has the ability to match "di nevicate";
The expression "chance_int_0 query_snow_int_4" (not directly present in the grammar but achievable as "chance query_snow") can therefore match "probabilit脿 di nevicate" in two different ways depending on which one produces the "di" part.
The parse tree shown above somehow shows that there is an ambiguity, but it does not introduces an _ambig node in the point where the ambiguity arises.
I'm sorry about the size of the grammar, but the original one was even bigger and I managed to extract just the minimum required to run the test.
You can run the test on your own if you just download the pastebin and invoke it with a python interpeter.
An important thing to note, is that without ambiguity="explicit", the result is a valid (and probably correct) tree:
start
weather_question
weather_question_int_13
question_snow
question_snow_int_53
motion_loc
motion_loc_int_1 c'猫
chance
chance_int_0
probabilit脿
di
query_snow
query_snow_int_4 nevicate
future_point_in_time
future_point_in_time_int_0 domani
Which leads me to believe that the bug is probably not in the Earley parser, but the subsequent ForestToAmbiguousTreeVisitor step. @night199uk Perhaps you'd be interested to know.
@FrancescoManfredi If you provide a much shorter example, there are better chances that we would take the time to resolve it.
Thank you for taking into considerations this issue.
I've reduced the complexity of the test and replaced the italian words with uppercase letters so it's easier to keep track of what happens.
Here is the new test: https://pastebin.com/L7BqFU2d
Now the parsed phrase is "A B C D E" and the parse tree that comes out is for the phrase "A B C D A B C D E".
I'm also pasting the grammar here:
start: weather_question
weather_question: question_snow
question_snow: motion_loc chance query_snow future_point_in_time
motion_loc: ML_0
ML_0: "A"
chance: CH_0 [CH_1]
CH_0: "B"
CH_1: "C"
query_snow: [QS_0] QS_1
QS_0: "C"
QS_1: "D"
future_point_in_time: FP_0
FP_0: "E"
%ignore " "
And the resulting parse tree:
start
weather_question
question_snow
motion_loc A
chance
B
C
query_snow D
motion_loc A
chance B
query_snow
C
D
future_point_in_time E
I narrowed this down to an even simpler version:
from lark import Lark
newG = """
start: ab bc d
!ab: "A" "B"?
!bc: "B"? "C"
!d: "D"
"""
l = Lark(newG, ambiguity='explicit')
p = l.parse("ABCD")
print(p.pretty())
The result is
start
ab
A
B
bc C
ab A
bc
B
C
d D
So the problem here is that the ambiguity node isn't created, and instead the two derivations are just appended to start.
Note that changing the first line to
start: ab bc "D"
Results in a different kind of error, where the ambiguity isn't even detected, and instead only one derivation is chosen (but at least output is a "correct" tree).
@night199uk Maybe you'd like to take a look?
Can we consider this issue resolved?
Looks like it's fixed. I consider this closed unless someone shows otherwise.