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

Question

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

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

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

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

---

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

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

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

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

“好吧……所以我有 EBNF 不知何故，我究竟该如何解析我的文本？什么？!生成一个完整的解析器？!”

---

我一直在思考这个问题。这是我想出的:

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

我可能是错的，因此这个问题:

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

Answer 1

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

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

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

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

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

现在，如果有人构建了一个非常好的动态解析器​​生成器并将其放入您正在使用的语言的库中，那么您可能就可以开始了。 (查看 Perl's MARPA 了解其中之一)。

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

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

你不会找到很多人。

[我亲自为几十种语言构建了解析器。始终成功地使用静态解析器生成器方案]。

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