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

Question

我听说“真正的编译器编写者”推出了他们自己的手工解析器，而不是使用解析器生成器。我也听说解析器生成器不会为真实世界的语言剪切它。据说，有很多特殊情况使用解析器生成器很难实现。我怀疑这一点：

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

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

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

Answer 1

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

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

编辑：链接到海湾合作委员会文件，详细说明原因和收益与成本分析的变化：http://gcc.gnu.org/wiki/New_C_Parser。

Answer 2

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

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

编辑： 添加

Answer 3

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