ANTLR vs. Happy vs. 其他解析器生成器 [英] ANTLR vs. Happy vs. other parser generators

问题描述

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

I want to write a translator between two languages, and after some reading on the Internet I've decided to go with ANTLR. I had to learn it from scratch, but besides some trouble with eliminating left recursion everything went fine until now.

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

However, today some guy told me to check out Happy, a Haskell based parser generator. I have no Haskell knowledge, so I could use some advice, if Happy is indeed better than ANTLR and if it's worth learning it.

特别让我担心的是我的翻译器需要支持宏替换，我还不知道在 ANTLR 中如何做.也许在Happy这更容易做到?

Specifically what concerns me is that my translator needs to support macro substitution, which I have no idea yet how to do in ANTLR. Maybe in Happy this is easier to do?

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

Or if think other parser generators are even better, I'd be glad to hear about them.

推荐答案

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

People keep believing that if they just get a parser, they've got it made when building language tools. Thats just wrong. Parsers get you to the foothills of the Himalayas then you need start climbing seriously.

如果您希望为构建语言翻译器提供工业级支持，请参阅我们的DMS 软件再造工具包.DMS 提供

If you want industrial-strength support for building language translators, see our DMS Software Reengineering Toolkit. DMS provides

• 基于 Unicode 的词法分析器
• 完整的上下文无关解析器(左递归?没问题！任意向前看?没问题.二义性语法?没问题)
• C、C#、COBOL、Java、C++、JavaScript、...的完整前端(包括 C 和 C++ 的完整预处理器)
• AST 的自动构建
• 支持使用任意范围规则构建符号表
• 属性语法评估，以构建利用树结构的分析器
• 支持控制和数据流分析(以及对完整的 C、Java 和 COBOL 的实现)，
• 使用源语言和目标语言的语法进行源到源转换
• AST 对源代码进行漂亮打印，重现目标语言文本

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

Regarding the OP's request to handle macros: our C, COBOL and C++ front ends handle their respective language preprocessing by a) the traditional method of full expansion or b) non-expansion (where practical) to enable post-parsing transformation of the macros themselves. While DMS as a foundation doesn't specifically implement macro processing, it can support the construction and transformation of same.

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

As an example of a translator built with DMS, see the discussion of converting JOVIAL to C for the B-2 bomber. This is 100% translation for > 1 MSLOC of hard real time code. [It may amuse you to know that we were never allowed to see the actual program being translated (top secret).]. And yes, JOVIAL has a preprocessor, and yes we translated most JOVIAL macros into equivalent C versions.

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

[Haskell is a cool programming language but it doesn't do anything like this by itself. This isn't about what's expressible in the language. Its about figuring out what machinery is required to support the task of manipulating programs, and spending 100 man-years building it.]

这篇关于ANTLR vs. Happy vs. 其他解析器生成器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！