5

我听说“真正的编译器编写者”使用他们自己的手工解析器而不是使用解析器生成器。我还听说解析器生成器不适合现实世界的语言。据推测，有许多特殊情况很难使用解析器生成器来实现。我对此表示怀疑：

  1. 从理论上讲，GLR 解析器生成器应该能够处理大多数编程语言设计（可能 C++ 除外......）
  2. 我知道至少一种使用解析器生成器的生产语言：Ruby [1]。
  3. 当我在学校上编译器课程时，我们使用了解析器生成器。

所以我的问题是：使用解析器生成器编写生产编译器是否合理，或者使用解析器生成器是否被编译器社区认为是一个糟糕的设计决策？

[1] https://github.com/ruby/ruby/blob/trunk/parse.y

4

3 回答 3

4

对于它的价值，我相信 GCC 使用了 4.0 之前的解析器生成器，然后切换到手写递归下降解析器，因为它更易于维护和扩展。

解析器生成器确实为“真实”语言“削减”了它，但是将您的语法转换为可行的东西的工作量呈指数增长。

编辑：链接到 GCC 文档，详细说明更改的原因和好处与成本分析： http: //gcc.gnu.org/wiki/New_C_Parser。

于 2011-06-17T16:41:37.113 回答
1

我在一家公司工作了几年，我们或多或少地在编写编译器。我们不太关心性能。只是减少工作/维护量。我们使用生成的解析器 + 手写代码的组合来实现这一点。理想的平衡是使用解析器生成器自动化简单、重复的部分，然后在自定义函数中处理困难的部分。

于 2011-06-18T22:31:24.897 回答
0

有时会使用两种方法的组合，例如使用解析器生成代码，然后“手动”修改该代码。

另一种方式是一些扫描器（词法分析器）和解析器工具允许他们添加自定义代码，附加到语法规则，称为“语义动作”。这种情况的一个很好的例子是，解析器检测通用标识符和一些自定义代码，将一些特定标识符转换为关键字。

编辑：添加“语义动作”

于 2011-06-17T22:39:15.867 回答