编译器是否有实际的自托管原因？

Question

如果引导语言中的编译器运行良好且可维护,为什么要更改它？举例来说,重新编写它的编译器在版本1.5中自我托管,这导致编译时间变慢:当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

对于一些具体原因有罗布派克的读幻灯片为什么他们搬到转到编译器去而不是C.幻灯片中的结论是:

1. 摆脱C是该项目的一个巨大进步.
2. 代码更清晰,可测试,易于使用,更易于使用.
3. 新的统一工具链减少了代码大小,提高了可维护性.灵活的工具链,便携性仍然至关重要.

根据语言的不同,您可能会有所不同.