我在研究编译器构造，当然我也在研究这些概念的现实世界实现。其中一个例子是Babel的解析器：Babylon。
我浏览了Babylon的代码，它似乎使用了一个自上而下的解析器，其中嵌入了特定的语义规则。src
我期望Babel使用LR解析器的一个成员，可能还有一个定义文件，其中语法生成与语义规则耦合在一起。为什么？主要是因为许多其他现实世界中的语言使用lr语法分析器生成器，如Yacc、Bison等，它们为您提供了确切的接口，并且似乎是表示这些规则的更清晰、更可维护的方式，当您考虑到Babel生活在Javascript标准的边缘，一直在实现新事物时，情况就更糟了。
我还构建了自上而下和自下而上(lr)解析器，我认为两者之间的实现难度没有太大差异(两者都同样困难：)
那么，为什么Babel的解析器使用自上而下的语法定向翻译，而不是我认为更结构化的方法呢？这背后的设计决策是什么？我错过了什么？
谢谢！
我觉得你真的在问两个(或者三个)问题，所以我会分别回答
一般来说，不同解析方法的优点和缺点是什么
自上而下与自下而上
对于手工编写的解析器，情况实际上非常清楚：自上而下的解析器更容易编写和维护，我甚至从未见过手工编写的自下而上的解析器。
对于解析器生成器，情况就不那么清楚了。这两种类型的解析器生成器都存在(例如，yacc和bison是自下而上的，ANTLR和JavaCC是自上而下的)。两者都有各自的优点和缺点，我认为没有太多理由说一种方法显然比另一种更好。
事实上，我想说，在自上而下和自下而上的解析之间做出决定通常是没有意义的。手工编写解析器时，请始终使用前者。当使用解析器生成器时，您应该简单地选择其功能最适合您的项目的工具，而不是基于它是生成自下而上还是自上而下的解析器。
手工编写的解析器与解析器生成器
手工编写解析器的原因有很多。这些还取决于哪种解析器生成器甚至可用于该语言。解析器生成器经常遇到的一个缺点是，它们很难为语法错误生成好的错误消息。
另一个可能的问题是，对于非上下文无关的语言，您可能需要一些肮脏的技巧来使用解析器生成器来实现它们，或者这可能根本不可能。
这些因素如何具体适用于巴比伦
手工编写的解析器与解析器生成器
JavaScript语法非常复杂，有很多特殊情况可以解决歧义。在使用解析器生成器时，这可能需要大量的技巧，而使用可用于JavaScript的解析器生成器可能根本不可能。
我还想说的是，可用于JavaScript的解析器生成器可能还没有准备好生产，而且在项目刚创建时更没有准备好。
自上而下与自下而上
正如我所说，我从来没有见过手工编写的自下而上的解析器。因此，一旦你决定使用手工编写的解析器，那么编写自上而下的解析器就很容易了。