解析器是一个接受输入字符串并吐出AST的东西。
解析器生成器是一种需要语法并吐出解析器的东西。
静态解析器生成器是一种语法，并为解析器吐出代码。
动态解析器生成器是在运行时
这让我大吃一惊，因为元编程通常比运行时替代方案更难。我理解为什么它更有效率，我明白为什么它不那么错误;我不明白的是它是如何成为常态的。
进入解析器世界令人沮丧。我无法理解为什么每个人都指着Yacc或Bison。我只是希望我的程序采用任意的EBNF，一个任意的输入字符串;并吐出AST。
＆＃34;在某些标准＆＃34;语法文件＆＃34;中，每种语言都有明确定义的EBNF somewhere 。格式。我可以编写一个编辑器来支持任何语言！＆＃34;
＆＃34;好的，没有发生。什么是解析器组合器？它们看起来很酷，但没有简单的方法将EBNF转换为一个。＆＃34;
＆＃34;好的......所以我有EBNF 以某种方式，我怎么解析我的文字？什么？！生成一个完整的解析器？！＆＃34;
我一直在考虑这个问题。以下是我提出的建议：
我可能错了，所以这个问题：
为什么静态解析器生成器比动态解析器生成器更普遍？
答案 0 :(得分：1)
[挑剔：解析器解析;他们发现子结构，并告诉你的输入是你指定langauge的有效短语。他们（大多数）不会建立AST。您通常可以使用代码来增强您的解析器描述[请参阅Bison或许多其他人]，这些代码通过在识别次要词语时发生的解析器回调来实现这一点。
真正的原因是对于任何特定工具，语法都不会非常快速地改变。您不需要动态解析器生成器。是的，早期的机器较小，无法提供空间或时间。
当前的工作站具有足够的容量，因此空间不再是问题。 现在问题是性能或工程上的不便。
性能方面，您可以使用动态解析器生成器来生成与静态解析器一样快的解析器，因此这不是问题。
问题是使用动态解析器生成器，我必须包含在我的应用程序中。除非它被设计成易于使用的插件，否则会很尴尬。更糟糕的是，我能得到/想要/好的那个可能与我的语言不匹配; Bison很容易插入java，因为它是C代码。因此，构建我的应用程序变得更加困难。
现在，如果某人构建了一个非常好的动态解析器生成器并将其放入您正在使用的语言库中，那么您可能会很高兴。 （查看其中一个的Perl's MARPA）。
但是，现在我们又回到了，您是否需要动态解析器生成？如果没有，静态的那些就好了，通常非常好。
如果你坚持使用你的应用程序，请派一个子任务来运行一个静态解析器生成器，并将其结果导入你的应用程序。 Voila，从静态解析器生成器生成动态解析器。
你不会找到很多人。
[我亲自为几十种语言构建了解析器。总是设法使用静态解析器生成器方案成功]。
[现在，我对解析器生成器的不满是他们通常不会构建AST，并且这比定义语法更难实现。 如果你制定了正确的规则，你可以让他们这样做;我使用的解析器生成器会自动执行此操作（请参阅bio），这对于大型语法来说是一个巨大的胜利]。