【发布时间】:2018-12-14 07:00:48
【问题描述】:
我知道语法中存在 First/First 和 First/Follow 冲突,这使得语法“不是 LL(1)”。我只是想知道语法中是否存在跟随/跟随冲突。
【问题讨论】:
标签: parsing compiler-construction ll
我知道语法中存在 First/First 和 First/Follow 冲突,这使得语法“不是 LL(1)”。我只是想知道语法中是否存在跟随/跟随冲突。
【问题讨论】:
标签: parsing compiler-construction ll
是的,这是可能的,但需要进行不寻常的配置才能实现。考虑下面的语法,它增加了一个新的开始符号:
S' → 新元
S → tT
T → A |乙
A → ε
B → ε
现在,让我们想象一下尝试填写我们的 LL(1) 解析表,如下所示:
$ t
+----------+----------+
S' | | S' -> S$ |
+----------+----------+
S | | S -> tT |
+----------+----------+
T | T -> A | |
| T -> B | |
+----------+----------+
A | A -> e | |
+----------+----------+
B | B -> e | |
+----------+----------+
请注意,(T, $) 的条目中有两个项目。这是有道理的:如果我们有活动的非终结符 T 并看到 $,我们知道我们需要选择一个将扩展为空字符串的产生式。我们有两种不同的方法:我们可以使用 T → A 或 T → B,最终目标是将这些非终结符中的每一个扩展为空字符串。这是个问题 - 我们无法预测要走哪条路线。
现在,这是什么类型的冲突?这不可能是 FIRST/FIRST 冲突,因为 FIRST(A) = {ε} 和 FIRST(B) = {ε},所以 A 和 B 在其第一组中都没有任何终端。出于同样的原因,它不能是 FIRST/FOLLOW 冲突。
这意味着这是罕见的 FOLLOW/FOLLOW 冲突 - 我们知道我们会根据 A 和 B 的 FOLLOW 集合中的内容选择产生式,但它们彼此完全相同,因此解析器可以'不要明确地选择下一步做什么。
【讨论】:
这可能是一个更简单的例子
S → A a
A → B | C
B → ε
C → ε
这里,由于a同时在B和C的FOLLOW中,所以在(A, a)上,A → B和A → C之间会发生冲突。请注意,没有其他冲突。
【讨论】: