生产编译器使用解析器生成器吗?

问题描述 投票:0回答:4

我听说“真正的编译器编写者”会推出自己的手工解析器,而不是使用解析器生成器。我还听说解析器生成器不适合现实世界的语言。据说,有许多特殊情况很难使用解析器生成器来实现。我对此有疑问:

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

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

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

parsing compiler-construction parser-generator
4个回答
4
投票

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

解析器生成器确实可以“剪切”“真正的”语言,但是将语法转换为可行的东西的工作量呈指数级增长。

编辑:链接到 GCC 文档,详细说明了更改的原因以及收益与成本分析:http://gcc.gnu.org/wiki/New_C_Parser.


1
投票

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


0
投票

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

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

编辑: 添加“语义动作”


0
投票

值得注意的是,CPython 使用解析器生成器:

大概也是为了对语言有更清晰的表示,尽管我还没有看到为什么使用解析生成器而不是手写生成器的明确理由。

© www.soinside.com 2019 - 2024. All rights reserved.