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