我非常喜欢使用 YARD：
http://code.google.com/p/yardparser/
http://www.codeproject.com/KB/recipes/yard-tokenizer.aspx
我能够构建功能齐全的计算器。我正在评估 YARD 来做 PHP 解析器。请就 PEG 语法和解析器生成器的限制提出建议。非常感谢你！
问问题
7400 次
2 回答
20
我认为 PEG 最大的“问题”是它们不适合正常的语法分类，因为它们以完全不同的方式运行。正常语法是“倒退”的，因为它们描述了可以生成的所有可能的句子（程序）。PEG 描述了如何解析——它们从另一端来解决问题。
在我看来，这是一种更自然的思考问题的方式，当然对于任何手写（递归下降）解析器，我不会做任何其他事情。
于 2009-12-06T23:45:30.710 回答
6
PEG 语法的主要限制是它们根本不处理歧义。
可以肯定的是，这也是他们的强项，因为处理歧义是使用 CFG（上下文无关语法）工具最令人沮丧的部分之一。
使用 PEG，您可以通过将您想要匹配的规则排在另一个可能匹配但您不想要的规则之前明确地处理歧义。
问题是你甚至不总是知道语言或语法和 PEG 生成器中的一些甚至任何歧义，至少我尝试过的那些，不要分析语法的歧义来帮助你找到然后设计和命令你的规则以正确的方式处理它们。
yacc 和 bison 等 CFG 解析器生成器会分析您的语法并报告所有歧义。不幸的是，他们经常以一种很难理解的非常神秘的方式报告它们。当然，通常很难修复语法来处理它们。但至少你会意识到它们的存在。
With a PEG grammar you can be blissfully ignorant of the ambiguities in your conceptual grammar because once you make it a PEG it doesn't have ambiguities any more, it just has matching rules and maybe silently unreachable rules which would also match if they had higher precedence. These might not show up in your testing but may show up after release.
With CFG grammars you are forced to deal with ambiguities during development, but it won't be easy.
In the event I'm not making it clear, here's a six-year-old discussion by Joshua Haberman over on the Lambda the Ultimate programming languages blog: PEGs and Packrat Parsing are not the answer.
于 2014-08-14T01:24:45.143 回答