如果语法不明确，那么每种句子形式都存在一个句柄。？
可以有两个产生式，我们可以从中进行缩减。根据需要给出优先级和关联后，将只有一个句柄。那么这一说法是否属实？
there can be two productions from which we can do the reduction. After giving precedence and associations as required there will be one handle only.so is this statement true??
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这部分是正确的，归约/归约冲突通常可以通过指定优先级或让解析器构建器选择在另一个规则之前应用哪个规则来解决。
这意味着冲突已解决，但并不意味着解析器将完全按照预期运行。研究导致冲突的原因并思考是否需要重构语法来表达您试图解析的内容或者自动选择/优先级是否足够，这很方便。
This is partially true, a reduce/reduce conflict is usually resolved by specifying precedence or by letting the parser builder choose which rule to apply before the other.
This means that the conflict is solved but not that the parser is going to behave exactly as intended. It is convenient to study what is causing the conflict and think if a refactoring of the grammar is needed to express what you are trying to parse or if the automatic choice/precedence is enough.
如果你的语法有不明确的规则，你就会得到多种解释。您不必坚持语法消除歧义；你可以简单地同意某些东西是不明确的，并以多种方式解析它：
解析的结果是多种解释。
现在，为了让这样的语言对读者有用，要么他必须对歧义感到满意，要么你需要给他一种解决它的方法。 （在这个例子中，我已经决定你对这种歧义感到高兴，因为我没有给你解决它的方法！）。或者，一个人可以为某些东西的读者提供不明确的解析，一种选择哪种解析有意义的方法，而他会拒绝不适当的解析。
对于上述情况，我可以通过告诉您我的意思是“水果 => 西瓜”来做到这一点。
计算机语法并没有什么不同，但大多数程序员不想要模糊的代码。所以一般来说，语言设计者喜欢定义明确的语法。在实践中，他们并没有成功，你会得到有趣的语言规则，比如“如果这可以被含糊地解释，那么就这样解释。”。
If you have a grammar which has ambiguous rules, you get multiple interpretations. You don't have to insist that the grammar removes ambiguity; you can simply agree that something is ambiguous and parse it multiple ways:
The result of the parse is multiple interpretations.
Now, for such a language to be useful to a reader, either he has to be happy with the ambiguity, or you need to give him a way to resolve it. (In the example, I've decided for you that you are happy the ambiguity, because I haven't given you a way to resolve it!). Or, one can provide the reader of something with ambiguous parsess, a way to choose which parse make sense, and he rejects the inappropriate parses.
I can do that for the above case by telling you that I mean "fruit => watermelon".
Computer grammars are not different, but most programmers don't want ambiguous code. So in general, langauge designers like to define unambiguous grammars. In practice, they don't succeed and you get funny language rules like, "If this could be interpreted ambiguously, then interpret it this way.".