生产编译器是否使用解析器生成器？

Question

我听说“真正的编译器编写者”会使用自己的手工解析器，而不是使用解析器生成器。我也听说过解析器生成器不会为真实语言剪切它。据说，使用解析器生成器很难实现许多特殊情况。我对此表示怀疑：

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

所以我的问题：使用解析器生成器编写生成编译器是合理的，还是使用编译器社区认为设计决策不好的解析器生成器？

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

Answer 1

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

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

编辑：链接到GCC文档，详细说明了原因和收益与成本分析的变化：http://gcc.gnu.org/wiki/New_C_Parser。

Answer 2

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

Answer 3

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

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

编辑： 添加“语义动作”