我正在研究编译器构建，我自然也在研究这些概念的现实实现。其中一个例子是巴贝尔的解析器：巴比伦。
我浏览了巴比伦的代码，它似乎使用了带有嵌入式临时语义规则的自上而下解析器。 src
我期待Babel使用LR解析器的成员，并且可能是一个定义文件，其中语法产生与语义规则耦合在一起。为什么？好吧，主要是因为一堆其他现实世界的langs使用lr解析器生成器，如Yacc，Bison等，它们为您提供了这个精确的界面，并且似乎是一种更清晰，更易于维护的方式来表示这些规则，甚至更多考虑到Babel生活在Javascript标准的边缘，一直在实现新的东西。
我也构建了自上而下和自下而上（lr）解析器，我也没有看到两者之间存在很大的实现难度差异（两者都同样困难:)）
那么，为什么Babel的解析器使用自顶向下的ad hoc语法定向翻译而不是我认为更结构化的方法呢？背后的设计决策是什么？我错过了什么？
谢谢！
答案 0 :(得分：5)
我觉得你真的要问两个（或者三个）问题，所以我会单独解决这些问题
对于手写解析器，情况实际上非常清楚：自上而下的解析器更容易编写和维护，甚至从未见过手写的自底向上解析器。
对于解析器生成器，情况不太清楚。存在两种类型的解析器生成器（例如，yacc和bison是自下而上的，ANTLR和JavaCC是自上而下的）。两者都有其优点和缺点，我不认为有很多理由说一种方法明显优于另一方法。
事实上，我说在自上而下和自下而上解析之间做出决定通常毫无意义。手写解析器时，请始终使用前者。使用解析器生成器时，您应该只选择最适合您项目的工具，而不是基于它是生成自下而上的解析器还是自上而下的解析器。
为什么人们会手写解析器有很多原因。这些还取决于哪种解析器生成器甚至可用于该语言。解析器生成器经常遇到的一个缺点是，它们很难为语法错误生成良好的错误消息。
另一个可能的问题是，对于非上下文免费语言，您可能需要使用解析器生成器来实现它们，或者根本不可能实现它们。
JavaScript语法非常复杂，有很多特殊情况可以解决歧义。使用解析器生成器时可能需要大量的攻击，并且可能根本不可能使用适用于JavaScript的解析器生成器。
我还要说，可用于JavaScript的解析器生成器可能还没有生产就绪，而且在首次创建项目时更是如此。
正如我所说，我从来没有见过一个手写的自下而上的解析器。因此，一旦您决定使用手写解析器，编写自上而下解析器的决定就不费吹灰之力了。