In what sense a type of parser is less power than the other? - Computer Science Stack Exchange most recent 30 from cs.stackexchange.com 2019-09-22T10:34:38Z https://cs.stackexchange.com/feeds/question/109521 https://creativecommons.org/licenses/by-sa/4.0/rdf https://cs.stackexchange.com/q/109521 2 In what sense a type of parser is less power than the other? anir https://cs.stackexchange.com/users/49261 2019-05-18T19:37:03Z 2019-05-26T20:21:31Z <p>I am learning LR(0), SLR(1), CLR(1) and LALR(1) parsers. I know how parsing tables of each of them is formed. If x &lt; y means parser x is less "powerful" that parser y, then, I read, the relationship between these parsers can be shown as:</p> <blockquote> <p>LR(0) &lt; SLR(1) &lt; CLR(1) &lt; LALR(1)</p> </blockquote> <p>However, I am not very clear about exactly what being "powerful" means. I can guess following possibilities for being less powerful:</p> <p>a. Cannot accept valid string<br> b. Accept valid string very late<br> c. Cannot reject invalid string<br> d. Reject invalid string very late<br> f. Involves SR, RR conflict for some grammars</p> <p><strong>Doubts</strong> </p> <ol> <li><p>I know point 5 holds for sure. However what exact effect a conflict have on parsing? Do we say that parser is non deterministic and/or requires backtracking to steps involving conflict or we simply say parser of certain type cannot be simply prepared for given grammar?</p></li> <li><p>Which of first four (a,b,c,d) holds? I tried solving one example, for which I prepared both SLR(1) and CLR(1) parsing table. I SLR(1) parsing table had reduce move for state <code>2</code> and terminal <code>)</code>, whereas CLR(1) did not. I took an invalid string for which SLR(1) was able to incorrectly reduce when stack top was state <code>2</code> and next input symbol was <code>)</code>. But eventually it failed to shift <code>)</code>. So, in the end rejecting the string. However, CLR(1) rejected the string right away without incorrectly reducing. Is this what all can happen? Or there can be an invalid string which SLR(1) may incorrectly accept (point c)? Or points (a) and (b) do also hold?<br> I feel only point (d) holds. Also SLR(1) and CLR(1) can accept valid string in same number of steps (that is, point b does not hold). Am I right with what I feel?</p></li> </ol> <h1> Edit</h1> <p>I concluded following for above points (a) through (d). Need someone to confirm:</p> <p><strong>(a)</strong> SLR(1) always accept valid strings as it will be able to correctly do shift reduce moves for such strings. So, point (a) is incorrect. </p> <p><strong>(b)</strong> Accepting valid strings late can only happen when valid string causes traversing through incorrect reduce moves of SLR(1) parsing table. However, this never happens. Valid strings can never be accepted by going through incorrect reduce move cells of parsing table. Those are only hit by invalid strings. Hence, point (b) is also wrong. </p> <p><strong>(c)</strong> SLR(1) can never fail to reject invalid string as it will always fail to shift some terminal in such string. So, point c is also not correct. </p> <p><strong>(d)</strong> SLR may reject some invalid strings late since it may do incorrectly do some reductions. So only point d is correct. </p> <p><strong>Another (possibly last) doubt</strong></p> <p>Though in (c) above, I said SLR(1) can never fail to reject invalid string, I doubt its correctness. If a parser accepts invalid string, we simply say that the parser does not implement that grammar, right? But my doubt is whether such parser always involve SR / RR and such "conflict is the only reason to fail to reject invalid string"? We know that SLR can do some incorrect reductions. So, "can't such incorrect reduction be reason for acceptance of invalid string"? Or in other words, for some invalid string, can't SLR shift all of it (so that no terminal will remain un-shifted in the end), and finally do incorrect reduction of whole invalid input string to starting symbol S, thus accepting invalid string? After all we know SLR parser may do some incorrect reductions. Then, why it cant do incorrect reduction of whole invalid input string to the start symbol? </p> https://cs.stackexchange.com/questions/109521/-/109578#109578 3 Answer by rici for In what sense a type of parser is less power than the other? rici https://cs.stackexchange.com/users/4416 2019-05-20T06:44:32Z 2019-05-22T22:56:06Z <p>Assuming that by "CLR" you mean "canonical LR", then you have the order wrong; the correct containment order is</p> <p><span class="math-container">\$LR(0) &lt; SLR(1) &lt; LALR(1) &lt; CLR(1)\$</span></p> <p>A possibly more meaningful way of saying that is that if we define <span class="math-container">\$G_X\$</span> to be the set of context-free grammars which can be parsed with algorithm <span class="math-container">\$X\$</span>, then</p> <p><span class="math-container">\$G_{LR(0)} \subset G_{SLR(1)} \subset G_{LALR(1)} \subset G_{CLR(1)}\$</span></p> <p>That containment sequence does not apply to <em>languages</em>. If we say that <span class="math-container">\$L_X\$</span> is the set of languages for which there is a grammar in <span class="math-container">\$G_X\$</span>, then we will find that</p> <p><span class="math-container">\$L_{LR(0)} \subset L_{SLR(1)} \subseteq L_{LALR(1)} \subseteq L_{CLR(1)}\$</span></p> <p>For all of these parsing algorithms, the fact that the algorithm cannot produce a conflict-free parsing table for a particular grammar means that that grammar cannot be parsed with that algorithm. The word "accept" is quite confusing here: an algorithm produces a parser from a grammar (or fails to do so); the parser then accepts those sentences which are in the grammar's language. If an algorithm produces a parser for a grammar, then that parser will be 100% precise: it will accept all sentences in that grammar's language and reject all other sentences. </p> <p>Furthermore, all these LR parsers have linear time and space complexity (in the size of the sentence to be recognised), and all of them reject invalid inputs at the earliest possible point, which is as soon as the prefix of the input cannot be the prefix of any sentence in the language. It is true that some of the parsers may perform extra reduce actions before reporting failure, but that is not considered in the definition of a grammar's "power".</p>