language-agnostic - 引导解释器？

我们知道编译器可以使用称为引导的技巧用它自己的语言编写。我的问题是这个技巧是否也适用于解释器？

理论上答案肯定是肯定的，但有人担心随着我们进行迭代，源代码的解释会变得越来越低效。那会是一个严重的问题吗？

我正在引导一个非常动态的系统，其中程序将不断变化，因此它排除了编译器。

让我这样拼写:

让 i 成为解释器。

让 L 成为编程语言。

我们可以在机器代码(最低级别)中编写 i1 来解释 L1。

然后我们在 L1 中编写 i2，解释 L2——一种新语言。

然后我们在 L2 中编写 i3，解释 L3——另一种新语言。

等等...

我们不需要上面的任何编译器，只需要解释器。正确的？

它可能效率低下。这是我的问题，如果它确实效率低下，如何克服它。

最佳答案

那没有意义。解释器不会生成二进制文件，因此无法创建可以独立运行的东西。在某个地方，最终，您需要有一个二进制文件作为解释器。

编译器引导的示例。假设我们有两种语言 A(ssembler) 和 C。我们想引导一个用 C 编写的 C 编译器。但我们只有一个汇编程序。

在 A

中编写基本的 C 编译器

用 C 编写 C 编译器，并用早期用 A 编写的编译器进行编译

你现在有一个可以自己编译的 C 编译器，你不再需要 A 或原始编译器了。

后来的运行变得只是

使用用 C 编写的编译器编译 C 程序

现在假设您有一种解释性语言，我将其称为 Y。第一个版本可以称为 Y1，下一个版本可以称为 Y2，依此类推。让我们尝试“引导”它。

首先，我们没有任何可以解释 Y 程序的东西，我们需要编写一个基本的解释器。假设我们有一个 C 编译器并用 C 编写了一个 Y1 解释器。

用 C 编写 Y1 解释器，编译它

在 Y1 中编写 Y2 解释器，在用 C

编写的 Y1 解释器上运行它

在 Y2 中编写 Y3 解释器，在 Y1 解释器上运行的 Y2 解释器上运行它...用 C 编写。

问题是您永远无法摆脱解释器堆栈，因为您永远不会编译更高级别的解释器。所以你总是需要编译和运行用 C 编写的第一个版本的解释器。你永远无法逃避它，我认为这是编译器引导过程的基本点。这就是为什么我说你的问题没有意义。

关于language-agnostic - 引导解释器？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/9853541/