与LR(1)相比,在SLR(1)解析器中查找导致冲突的字符串有多么容易

时间:2018-12-15 16:44:03

标签: parsing compiler-construction grammar compiler-theory lr

众所周知,SLR(1)解析器的状态通常少于LR(1)。难道是因为这样而容易或难于在LR(1)中找到导致SLR(1)解析器发生冲突的字符串?为什么?

谢谢。

1 个答案:

答案 0 :(得分:0)

假设您有一些CFG,并且为该语法构建了SLR(1)解析器和LR(1)解析器。如果您没有任何移位/减少或减少/减少冲突的方法,那么您就完成了-没有任何导致冲突的字符串。另一方面,如果存在这样的冲突,则是的,存在导致冲突的字符串。您可以通过在自动机中向后工作来找到这样的字符串:查找从起始状态到具有shift / reduce或reduce / reduce冲突的状态的路径,并写出一系列带您到达的终端和非终端。如果都是终端机,那就太好了!您已经有了字符串。如果那里有任何非终结点,由于LR解析器会反向追踪最右边的派生,请按照找到的顺序选择最右边的非终结点,然后重复此过程以进一步扩展它。最终,您会得到字符串。

从这种意义上讲,一旦您构建了自动机,完全相同的过程将发现无法解析的字符串。因此,找到坏字符串的困难基本上归结为建立SLR(1)与LR(1)自动机的问题,这就是LR(1)自动机比SLR(1)自动机大一点的事实。找出语法不是LR(1)可能要比发现语法不是SLR(1)花费更长的时间,这仅仅是因为构建LR(1)解析器需要更多的时间。