javascript - 为什么 Babel 使用自上而下的解析器？

Question

我正在研究编译器构造，当然我也在研究这些概念在现实世界中的实现。一个例子是 Babel 的解析器:Babylon。

我查看了 Babylon 的代码，它似乎使用了带有嵌入式特殊语义规则的自上而下解析器。 src

我原以为 Babel 会使用 LR 解析器的一个成员，并且可能是一个定义文件，其中语法产生式与语义规则耦合在一起。为什么？好吧，主要是因为许多其他现实世界的语言使用 lr 解析器生成器，例如 Yacc、Bison 等，它们为您提供了这个确切的接口(interface)，并且似乎是表示这些规则的更清晰和更易于维护的方式，甚至当您考虑到 Babel 处于 Javascript 标准的边缘，一直在实现新事物。

我还构建了自上而下和自下而上 (lr) 解析器，我没有发现两者之间存在很大的实现难度差异(两者同样困难 :))

那么，为什么 Babel 的解析器使用自上而下的特殊语法定向翻译，而不是我认为更结构化的方法？这背后的设计决策是什么？我错过了什么？

谢谢!

Answer 1

我觉得你真的在问两个(或三个)问题，所以我会分别解决它们

一般来说，不同解析方法的优缺点是什么

自上而下与自下而上

对于手写的解析器，情况实际上非常清楚:自上而下的解析器更容易编写和维护，以至于我从未见过手写的自下而上的解析器。

对于解析器生成器，情况不太清楚。存在两种类型的解析器生成器(例如，yacc 和 bison 是自下而上的，而 ANTLR 和 JavaCC 是自上而下的)。两者各有优缺点，我认为没有理由说一种方法明显优于另一种方法。

事实上，我认为在自上而下和自下而上的解析之间做出选择通常是没有意义的。手写解析器时，请始终使用前者。使用解析器生成器时，您应该简单地选择其功能最适合您的项目的工具，而不是根据它生成的是自下而上还是自上而下的解析器。

手写解析器与解析器生成器

人们手写解析器的原因有很多。这些还取决于哪些解析器生成器甚至可用于该语言。解析器生成器经常遇到的一个缺点是它们很难为语法错误生成良好的错误消息。

另一个可能的问题是，对于非上下文无关语言，您可能需要一些肮脏的黑客来使用解析器生成器来实现它们，或者它可能根本不可能。

这些因素如何特别适用于巴比伦

手写解析器与解析器生成器

JavaScript 语法相当复杂，有很多特殊情况来解决歧义。在使用解析器生成器时可能需要大量的 hack，而对于可用于 JavaScript 的解析器生成器可能根本不可能。

我还要说的是，可用于 JavaScript 的解析器生成器可能还没有准备好生产，而且在项目刚创建时就更不用说了。

自上而下与自下而上

正如我所说，我从未见过手写的自下而上的解析器。因此，一旦您决定使用手写解析器，编写自顶向下解析器的决定就很容易了。