众所周知,SLR(1)解析器的状态通常少于LR(1)。难道是因为这样而容易或难于在LR(1)中找到导致SLR(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)解析器需要更多的时间。>