ANTLR与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源代码精心打印，以重现目标语言文本

关于OP处理宏的请求：我们的C，COBOL和C ++前端通过a）传统的完全扩展方法或b）非扩展（在可行的情况下）来处理它们各自的语言预处理，以实现后解析转换宏本身。虽然DMS作为基础并没有专门实现宏处理，但它可以支持它的构建和转换。

作为使用DMS构建的翻译器的示例，请参阅讨论 converting JOVIAL to C for the B-2 bomber。这是＆gt;的100％翻译1 MSLOC很难 实时代码。 [可能会让你知道我们从未被允许看到正在翻译的实际节目（绝密）。是的，JOVIAL有一个预处理器，是的，我们将大多数JOVIAL宏翻译成等效的C版本。

[Haskell是一种很酷的编程语言，但它本身并没有做这样的事情。 这不是关于语言中可表达的内容。它是关于确定支持操作程序任务所需的机器，以及 花费100人年来建造它。]