SLR 分析表

完整项目说“右部已经齐了”，FOLLOW 再问“它若现在结束，下一个 token 能接在它后面吗？”一个输入 token 不能跟在 $A$ 后面，就可排除在此刻把整段压成 $A$。

但 FOLLOW 把 $A$ 的所有出现上下文混在一起。同一个 $A$ 在另一个位置能跟 =，不保证它在当前项目状态中也能跟 =。所以这是一种可靠但可能过宽的上下文近似。过宽不会漏掉文法需要的归约，却可能保留冲突，使 SLR 无法给出确定动作。

用 FOLLOW 修复一个真实的 LR(0) 冲突 ​

取 $r_1:E\to T+E$，$r_2:E\to T$，$r_3:T\to \mathrm{id}$。这里是右递归表达式文法。读到一个 $T$ 后的状态为

LR(0) 在 + 上既填移进，又因完整项目填归约 $r_2$，发生冲突。实际 FOLLOW 集是

因此 SLR 只在 $\mathrm{\$}$ 上将 $T$ 归约为 $E$；+ 列只剩移进。六状态的全部表如下：

其中 $I_0$ 预测全部规则；$I_1$ 只含 $E^{\prime }\to E\cdot$；$I_3$ 只含 $T\to \mathrm{id}\cdot$；$I_4$ 含 $E\to T+\cdot E$ 及开始解析 $E,T$ 的闭包；$I_5$ 只含 $E\to T+E\cdot$。

解析 id+id 时，状态栈依次为

动作依次是移进 id、$T\to \mathrm{id}$、移进 +、移进 id、$T\to \mathrm{id}$、$E\to T$、$E\to T+E$，最后在 $\mathrm{\$}$ 接受。两次到达状态2时的动作不同，正是下一 token 为 + 还是 $\mathrm{\$}$ 的区别。

FOLLOW 也可能太宽 ​

考虑赋值文法：

从初态识别 $L$ 后，项目集含

第一个项目要求可以移进 =。另一方面，$S\to L=R$ 让 = 属于 FOLLOW($L$)，$L\to \ast R$ 又让 FOLLOW($L$) 进入 FOLLOW($R$)，因此 = 也属于 FOLLOW($R$)。SLR 遂在同一格放入 $R\to L$ 归约。

这个信息并非凭空产生：在 *R=R 一类句型中，内部的 $R$ 确实可能面对 =。问题是当前栈只有作为整个句子开头的 $L$，若此时走 $S\to R\to L$，它后面应是结束标记，而不是赋值号。全局 FOLLOW 没保存这一区别。

规范 LR(1)公理库规范 LR(1) 分析Canonical LR(1) parsing在项目中保存局部右上下文，以一个向前看token区分归约的LR构表方法。在当前完整项目后附的向前看集合只有 $\{\mathrm{\$}\}$，因此能够移进 = 而不发生冲突。不能以“SLR有冲突”推断这份文法有歧义，也不应随意删掉一条产生式来压掉报错。

SLR 不增加 LR(0) 状态数。若实际自动机有 $q$ 个状态，构表除了原有项目/边枚举，还需计算 FOLLOW，并对每个完整项目填相应集合中的列；稠密表空间仍为 $O(q(|V|+|\mathrm{\Sigma }|))$。固定文法的解析驱动成本仍为线性时间及最坏线性栈空间。

安全性来自 FOLLOW 的必要条件：合法句柄归约后面出现的 token 必在相应 FOLLOW 中，所以限制归约不会删掉一条合法最右推导所需的动作。若剩余每格唯一，驱动器便能确定地执行；若仍有冲突，算法报告的是适用条件失败，而不是凭启发式冒充同一可靠性定理。

一个实用检查顺序是：先列出冲突状态的完整项目与移进项目，再算涉及的 FOLLOW，最后问这些 FOLLOW 元素来自哪些文法出现位置。这样能区分真正的歧义与全局上下文合并造成的伪冲突，也能看清下一步是否需要 LR(1)。