parsing - 使用 lex/yacc 替代方案的原因？

Question

大约每年一次，我必须开发或至少设计一个语法和一个解析器——这似乎是我工作生活中的常态。

每次我面临这个任务时，大约一年一次，我，一个相当 lex/yacc (flex/bison resp.) 的家伙，考虑或重新考虑普通 lex/yacc 的替代方案，经过一些思考和尝试后，我回到普通的 lex/yacc。

因为我在应用程序的中心有一个 CORBA 服务器，我可以从几乎所有语言编写的解析器中调用，所以这次我看了一下

antlr4 (Java) 和 antlr3 (Java 但有其他语言的 RT)，

SableCC (Java),

Parse::EBNF、Parse::Yapp 和 Marpa (Perl)、

和 SimpleParse (Python)，

对我来说，带有 antlrworks 的串联 antlr4 看起来是最有前途的候选者，但我还不相信花在进入它上的时间最终会被摊销。

我要开发的语法类似于SQL DDL(在结构方面，而不是在主题方面)。

为什么任何替代方法都会使我的任务比使用普通 lex/yacc 更容易？

Answer 1

您还应该考虑的是，各种解析器生成器会生成完全不同的解析器。 Yacc/bison 产生自底向上的解析器，这些解析器通常难以理解、难以调试并给出奇怪的错误消息。例如，ANTLR 产生一个递归下降自顶向下的解析器，它是 多更容易理解，您实际上可以轻松调试它，您只能将子规则用于解析操作(例如，仅解析表达式而不是完整语言)。

此外，它的错误恢复要好得多，并且会产生更清晰的错误。有各种IDEs/plugins/extensions这使得使用 ANTLR 语法变得非常容易(ANTLRWorks、IntelliJ 插件、Visual Studio Code 扩展等)。并且您可以使用相同的语法生成不同语言(C、C++、C#、Java 等)的解析器(除非您的语法中有特定于语言的操作，否则您已经在问题中提到了这一点)。当我们谈到 Action 时:由于底部解析器中的评估原则(移动标记，移动标记，将它们减少到新标记并移动它等)， Action 很容易在那里引起麻烦，例如执行不止一次等等。 ANTLR 生成的解析器并非如此。

多年来，我也尝试了各种解析器生成器，甚至自己编写了解析器生成器，但我会随时推荐 ANTLR 作为首选工具。