当GLR解析器以两种方式将某些文本缩减到同一个非终端时，它会合并解析子树。 Rekers使用'符号节点'。
我不是每个非终端都可能导致合并。事先知道非终端从未合并的内容将大大简化解析树的构建。
例如，在Elkhound Technical Report中，作者为GLR解析器实现了C ++语法。他描述了它：
语法目前有37个移位/减少冲突，47个减少/减少冲突和 8个模糊的非终结。
如何为给定的CFG分离含糊不清且无明确的非终结符？我在哪里可以读到这个？
答案 0 :(得分：0)
如何知道哪些非终端能够产生歧义，以实际方式简化解析树的构建？
如果你在语法中没有这样的非终结符，那么你可以省略符号节点构造和子树共享机制，为真。代码并不多，所以这次胜利很小。
但如果任何非终结者可能含糊不清，那么你需要机器。在所有歧义中共享该机制非常简单（我构建了GLR解析器）。那么你究竟获得了什么？
最后，你通常不能（定理）确定语法是否含糊不清。由于非终结符表示子语法，因此通常无法确定是否有任何特定的非终结符号不明确。您可以针对许多特殊情况执行此操作。 （事实上，我的GLR解析器生成器基本上会通过枚举非终结符的可能扩展来自动发现一些歧义。）