parsing - ANTLR vs. Happy vs. 其他解析器生成器

Question

我想在两种语言之间编写一个翻译器，在互联网上阅读了一些内容后，我决定使用 ANTLR。我必须从头开始学习它，但除了消除左递归的一些麻烦之外，直到现在一切都很好。

然而，今天有人告诉我去看看 Happy，一个基于 Haskell 的解析器生成器。我没有 Haskell 知识，所以我可以使用一些建议，如果 Happy 确实比 ANTLR 更好并且是否值得学习。

具体让我担心的是我的翻译器需要支持宏替换，我还不知道如何在 ANTLR 中做到这一点。也许在Happy这更容易做到？

或者如果认为其他解析器生成器更好，我很高兴听到它们。

Answer 1

人们一直相信如果他们得到一个解析器，他们就已经完成了
在构建语言工具时。那是错误的。解析器将您带到山麓
喜马拉雅山那么你需要开始认真攀登。

如果您想要构建语言翻译器的工业级支持，请参阅我们的
DMS Software Reengineering Toolkit . DMS 提供

基于 Unicode 的词法分析器

完整的上下文无关解析器(左递归？没问题!任意前瞻？没问题。二义性语法？没问题)

C、C#、COBOL、Java、C++、JavaScript、...的完整前端
(包括 C 和 C++ 的完整预处理器)

AST 的自动构建

支持使用任意范围规则构建符号表

属性语法评估，以构建利用树结构的分析器

支持控制和数据流分析(以及对完整 C、Java 和 COBOL 的实现)，

使用源语法和目标语言的源到源转换

AST 对源代码进行 pretty-print ，重现目标语言文本

关于 OP 处理宏的请求:我们的 C、COBOL 和 C++ 前端通过 a) 传统的完全扩展方法或 b) 非扩展(如果可行)来处理它们各自的语言预处理，以启用宏本身的解析后转换.而作为基础的DMS并没有具体实现宏处理，它可以支持宏处理的构建和转换。

作为使用 DMS 构建的翻译器的示例，请参阅讨论
convertingJOVIAL to C for the B-2 bomber .这是 > 1 MSLOC 的 100% 翻译
实时代码。 [知道我们从未被允许看到正在翻译的实际程序(绝密)，您可能会觉得很有趣。]。是的，JOVIAL 有一个预处理器，是的，我们将大多数 JOVIAL 宏翻译成等效的 C 版本。

[Haskell 是一种很酷的编程语言，但它本身并没有做这样的事情。
这与语言中可以表达的内容无关。它是关于弄清楚需要什么机器来支持操作程序的任务，以及
花了 100 人年的时间来 build 它。]