为什么静态解析器生成器比动态解析器​​生成器更普遍？

Question

解析器是一种接受输入字符串并输出 AST 的东西。

解析器生成器是一种接受语法并生成解析器的东西。

静态解析器生成器是一种接受语法并为解析器生成代码的东西。

动态解析器生成器是在运行时获取语法并在运行时生成解析器的东西.

---

这让我大吃一惊，因为元编程通常比运行时替代方案更难。我理解为什么它更有效，我理解它为什么错误更少；我不明白它是如何成为常态的。

进入解析器的世界令人沮丧。我不明白为什么每个人都一直指向 Yacc 或 Bison。我只是想让我的程序接受一个任意的 EBNF，一个任意的输入字符串；并吐出AST。

“每种语言在某处都有明确定义的可用EBNF，采用某种标准的“语法文件”格式。我可以编写一个编辑器来支持任何语言！” p>

“好吧，没有发生。解析器组合器到底是什么？它们看起来很酷，但是没有简单的方法将 EBNF 转换为一个。”

“好的...所以我有 EBNF 不知何故，我到底要如何解析我的文本？什么？！生成一个完整的解析器？！”

---

我一直在考虑这个问题。这是我想出的：

• 计算机运行缓慢。编译器是必要的。当时，编写生成解析器的东西似乎比手工编写更明智。
• 解析器很难推理，以至于编写动态生成的解析器实际上比静态生成的更难。
• 有些人认为静态解析器生成器是他们的路要走，编写了一个成功的实现，由于流行的使用，该实现现在已成为常态。

我可能错了，所以这个问题：

为什么静态解析器生成器比动态解析器​​生成器更普遍？

Answer 1

[吹毛求疵：解析器解析；他们发现子结构并告诉您的输入是您指定的语言的有效短语。他们（大部分）不构建 AST。您通常可以使用在识别子短语时发生的解析器回调执行此操作的代码来增强您的解析器描述[参见 Bison 或许多其他]。

真正的原因是，对于任何特定的工具，语法都不会很快改变。您不需要动态解析器​​生成器。是的，早期的机器更小，在空间和时间上都买不起。

当前工作站有足够的容量，因此空间不再是问题。 现在的问题是性能或工程不便。

在性能方面，您可能会得到一个动态解析器​​生成器来生成运行速度与静态解析器一样快的解析器，所以这不是真正的问题。

问题是使用动态解析器​​生成器，我必须将其包含在我的应用程序中。除非它被设计成一个易于使用的插件，否则会很尴尬。更糟糕的是，我能得到/想要/很好的可能与我的语言不符； Bison 不会轻易插入 java，因为它是 C 代码。所以构建我的应用程序变得更加困难。

现在，如果有人构建了一个非常出色的动态解析器​​生成器并将其放入您正在使用的语言的库中，那么您可能会很高兴。 （查看Perl's MARPA 了解其中之一）。

但是，现在我们回到，您需要动态解析器​​生成吗？如果没有，静态的就好了，而且通常非常好。

如果您坚持... 从您的应用程序中派生一个子任务以运行静态解析器生成器，并将其结果导入您的应用程序。瞧，从静态解析器生成器生成动态解析器​​。

你不会找到很多接受者。

[我亲自为数十种语言构建了解析器。总是设法通过静态解析器生成器方案成功]。

[现在，我对解析器生成器的不满是它们通常不构建 AST，而且实现起来总是比定义语法更难。 如果你制定了正确的规则，你可以让他们这样做；我使用的解析器生成器会自动执行此操作（请参阅 bio），这对于大型语法来说是一个巨大的胜利]。