language-agnostic - 引导解释器？

Question

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

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

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

让我这样说:

让我成为解释器。

让 L 成为编程语言。

• 我们可以用机器代码(最低级别)编写 i1 来解释 L1。
• 然后我们在 L1 中写入 i2，解释 L2——一种新语言。
• 然后我们在 L2 中编写 i3，解释 L3——另一种新语言。
• 等等...

上面我们不需要任何编译器，只需要解释器。对吧？

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

Answer 1

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

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

1. 用A编写基本的C编译器
2. 用 C 编写 C 编译器，并用早期用 A 编写的编译器编译
3. 您现在有了一个可以 self 编译的 C 编译器，您不再需要 A 或原始编译器。

以后的运行变得公正

1. 使用C语言编写的编译器编译C程序

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

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

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

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