是否可以创建一个独立于原始解释器的“引导”解释器？

Question

根据维基百科，在编写编译器的上下文中，“引导”一词的意思是维基百科，在编写编译器的上下文中，“引导”一词的意思是的说法：

在计算机科学中，引导是用它要编译的源程序语言编写编译器(或汇编程序)的过程。应用此技术将导致自托管编译器。

我能理解这是怎么回事。然而，对于口译员来说，情况似乎有点不同。当然，现在可以编写一个自托管解释器了。这不是我要问的。我实际上想问的是:是否有可能使一个独立于最初的第一个解释器的自我托管的解释器。为了解释我的意思，考虑一下这个例子：

您用X语言编写您的第一个解释器版本，解释器用于您正在创建的一种新语言，名为Y。您首先使用语言X的编译器创建一个可执行文件。现在，您可以使用用X语言编写的解释器来解释用新语言Y编写的文件。

现在，据我所知，要想“引导”你用X语言编写的解释器，你需要用Y语言重写解释器。但这里有一个问题:即使你用Y语言重写了整个解释器，你仍然需要用X语言编写的原始解释器。因为要用Y语言运行解释器，就必须解释源文件。但是，究竟什么才能解释源文件呢？当然，这不可能什么都不是，所以你不得不继续使用第一个解释器。

无论您用Y语言编写了多少新的解释器，您都必须使用用X编写的第一个解释器来解释后续的解释器。这似乎是一个问题，仅仅是因为口译员的性质。

然而，另一方面，这篇维基百科关于口译员的文章实际上谈到了自我托管的解释器。这篇维基百科关于口译员的文章实际上谈到了自我托管的解释器。。以下是一个与此相关的小摘录：

自我解释器是用一种程序设计语言编写的能够自我解释的语言解释器；一个例子是用BASIC编写的基本解释器。自解释器与自托管编译器有关。如果不存在用于解释语言的编译器，则创建自我解释器需要用宿主语言(可能是另一种编程语言或汇编程序)实现该语言。通过拥有这样的第一个解释器，可以引导系统，并且可以用语言本身开发新版本的解释器。

但我仍然不清楚，这到底是如何做到的。看起来，无论如何，您总是会被迫使用用宿主语言编写的解释器的第一个版本。

现在，上面提到的文章指向另一篇文章的链接，其中维基百科给出了一些假设的自托管解释器示例。。然而，仔细研究后发现，许多自托管解释器(特别是一些更常见的解释器，如PyPy或Rubinius)的主要“口译”部分实际上是用其他语言编写的，比如C++或C。

那么我上面描述的可能吗？一个自我托管的解释器能独立于它原来的主机吗？如果是这样的话，究竟是怎样做的呢？

Answer 1

您正确地注意到，自托管解释器仍然需要一个解释器来运行自己，并且不能像编译器那样引导。

然而，自托管语言与自我托管的解释器并不是一回事.构建解释器通常比构建编译器容易。因此，为了实现一种新的语言，我们可能首先用一种无关的语言实现一个解释器。然后我们可以使用那个解释器来为我们的语言开发一个编译器。因为编译器是被解释的，所以语言是自托管的.然后编译器可以自己编译，然后可以被认为完全引导。

这方面的一个特例是自托管JIT编译运行时。它可以从主机语言的解释器开始，然后使用新语言实现JIT编译，然后JIT编译器可以自己编译。这感觉就像一个自我托管的解释器，但避免了无限解释器问题。这种方法是使用的，但还不是很普遍。

另一个相关的技术是一个可扩展的解释器，在这里我们可以在被解释的语言中创建扩展。例如，我们可以在语言中实现新的操作码。只要我们避免循环依赖，这就可以将基本解释器转换为功能丰富的解释器。

实际发生的情况通常是语言影响自己解析的能力，例如解析时间评估的宏。由于宏语言与正在处理的语言是相同的，它往往比专用或受限的宏语言更丰富的特性。但是，正确地指出，执行扩展的语言与扩展后的语言略有不同。

当使用“真正”的自我托管口译员时，这通常是出于教育或研究的原因。例如，在Scheme中实现一个解释器是教授编程语言的一种很酷的方法(参见SICP)。