compiler-construction - 编译器自托管是否有实际原因？

Question

如果您的 bootstrap 语言编译器运行良好且可维护，为什么要更改它？例如，Go 在 1.5 版本中将其编译器重新编写为自托管，导致 compile times to become much slower :当 Go 的目标是快速编译时，这是一个明显的不利因素。

Answer 1

一个实际原因是 社区 .如果编译器是用同一种语言编写的，那么用你的语言编程的人可能更喜欢在编译器中编程。如果我的编译器是 Fortran/COBOL 并且它生成 Go我不太可能将 Go 开发人员吸引到编译器。

另一个是构建链，即 依赖项 .如果您有一个用一种语言编写并生成另一种语言的编译器，那么您需要编写两组测试，当您可以满足其中一个时。这也降低了入门阈值，即您不需要开发人员了解多个工具链等。充分了解两种语言以在这两种语言中成为称职的编译器编写者是一项艰巨的工作，并缩小了您寻求帮助的潜在受众范围。 获得帮助对于大多数开源项目非常重要，任何增加潜在开发人员基础的事情都是一个明确的实际优势。

您还可以将测试列为额外的好处。如果您编写了自托管编译器，那么该语言需要做很多事情才能使自托管变得相对容易(而不是拔牙)，即文件 IO、字符串操作、符号表、树和列表等。显然您可以在没有所有这些的情况下生存，但它开始使编写编译器变得更加困难。这种坐在吃你自己的狗粮营地。

它被认为是 Rite of Passage但我不认为这是一个非常实际的原因，除非你能证明它吸引开发人员或其他一些原因来做它，也许对成就感觉良好是一个实际的好处，即你不太可能放弃它。

这里有一个有趣的话题......

https://softwareengineering.stackexchange.com/questions/263651/why-are-self-hosting-compilers-considered-a-rite-of-passage-for-new-languages

出于某些具体原因，请阅读 Rob Pikes 幻灯片，了解他们为何将 Go 编译器移至 Go instead of C .幻灯片中的结论是:

摆脱 C 对项目来说是一个巨大的进步。

代码更干净、可测试、可分析、更易于处理。

新的统一工具链减少了代码大小，提高了可维护性。
灵活的工具链，可移植性仍然至关重要。

根据语言的不同，您来往的好处可能会有所不同。