0

It is known that SLR(1) parsers usually have less states than LR(1). But is it easier or harder because of this to find a string that leads to conflict in a SLR(1) parser compared to a LR(1) and why?

Thank you in advance.

Dragonite LvL 100
  • 11
  • 1
  • 7
  • If, by "conflict", you mean a state with a parsing conflict, then you don't actually have an SLR(1) or LR(1) parser, you have a failure in the parser construction algorithm. – Michael Dyck Dec 16 '18 at 17:02

1 Answers1

0

Let’s say you have some CFG and you build both an SLR(1) parser and an LR(1) parser for that grammar. If you don’t have any shift/reduce or reduce/reduce conflicts, then you’re done - there aren’t any strings that lead to conflicts. On the other hand, if such a conflict exists, then yes, there is a string that leads to a conflict. You can find such a string by working backwards through the automaton: find a path from the start state to the state with the shift/reduce or reduce/reduce conflict and write out the series of terminals and nonterminals that take you there. If it’s all terminals, great! You’ve got your string. If there are any nonterminals there, since an LR parser traces a rightmost derivation in reverse, pick the rightmost nonterminal in the sequence you found and repeat this process to expand it out further. Eventually you’ll get your string.

In that sense, once you have the automata constructed, the exact same procedure will find a string that can’t be parsed. So the difficulty of finding a bad string basically boils down to building out the SLR(1) versus LR(1) automata, and that’s where the fact that LR(1) automata are a bit bigger than SLR(1) automata come in. It’ll probably take a bit longer to find out that a grammar isn’t LR(1) than to find out that it isn’t SLR(1) simply because it takes more time to build LR(1) parsers.

templatetypedef
  • 362,284
  • 104
  • 897
  • 1,065