我非常喜欢使用 YARD：
http://code.google.com/p/yardparser/
http://www.codeproject.com/KB/recipes/yard-tokenizer.aspx
我能够构建功能齐全的计算器。我正在评估 YARD 来做 PHP 解析器。请就 PEG 语法和解析器生成器的限制提出建议。非常感谢！
【问题讨论】：
标签： parser-generator yard peg php-parser
我认为 PEG 的最大“问题”是它们不适合正常的语法分类，因为它们以完全不同的方式运行。正常语法是“倒退”的，因为它们描述了所有可能生成的句子（程序）。 PEG 描述了如何解析——它们从另一端来解决问题。
在我看来，这是一种更自然的思考问题的方式，当然对于任何手写（递归下降）解析器，我不会做任何其他事情。
【讨论】：
PEG 语法的主要限制是它们根本不处理歧义。
当然，这也是他们的强项，因为处理歧义是使用 CFG（上下文无关语法）工具最令人沮丧的部分之一。
使用 PEG，您可以通过将您想要匹配的规则排在另一个可能匹配不明确但您不想要的规则之前，明确地处理歧义。
问题在于，您甚至不总是知道语言或语法中的一些或什至任何歧义，而 PEG 生成器，至少我尝试过的那些，不要分析语法以找出歧义帮助您找到它们，然后设计和订购您的规则以正确处理它们。
像 yacc 和 bison 这样的 CFG 解析器生成器会分析您的语法并报告所有歧义。不幸的是，他们经常以一种很难理解的非常神秘的方式报告它们。当然，通常很难修复语法来处理它们。但至少你会意识到它们的存在。
使用 PEG 语法，您可以很高兴地对概念语法中的歧义一无所知，因为一旦将其设为 PEG，它就不再有歧义，它只有匹配的规则，也许默默无法达到的规则也会匹配，如果他们有更高的优先级。这些可能不会出现在您的测试中，但可能会在发布后出现。
使用 CFG 语法，您不得不在开发过程中处理歧义，但这并不容易。
如果我没有说清楚，这里是 Joshua Haberman 在 Lambda the Ultimate 编程语言博客上的六年讨论：PEGs and Packrat Parsing are not the answer em>。
【讨论】：