Closed FrankC01 closed 6 years ago
I don't have time to super dig it ATM, but you may want to try resolving your shift/reduce conflicts. S/R conflicts can produce unexpected parsers.
Thanks for the quick reply... any reference to where I can go learn shift/reduce conflicts to know where that may be occuring?
It's happening because of the expression: expression SUB expression
/expression: expression SUM expression
rules. Because these rules have equal precedence, either order-of-operations is valid from the parser's perspective (don't let your grade school math teacher find out!)
If you work through the example in https://rply.readthedocs.io/en/latest/users-guide/parsers.html#generating-parsers you'll see how precedence is used.
I was able to remove the shift/reduce by basically just commenting it out and changing the main production to "PRINT SEMI_COLON" and passing in "print ;" but the exception still occurs. I will look at your reference but it feels as though there should be an 'end' production to handle the lookahead?
UPDATE I added the precedence which took care of the shift/reduce but it didn't make a difference. Could it be using Python 3.7?
found the issue
prior to the parse I was exhausting the tokens
Hai,
Can i know were you made the corrections.
I am also facing a similar problem:
/home/jm/Documents/Compiler Project/parser.py:38: ParserGeneratorWarning: 4 shift/reduce conflicts
return self.pg.build()
Traceback (most recent call last):
File "main.py", line 14, in
I'm getting this exception:
When attempting to parse:
Given this token list:
And this parser: