【发布时间】：2018-09-26 12:06:42
【问题描述】：
我正在尝试理解元循环评估器的概念。根据Wikipedia
在计算中，元循环评估器或元循环解释器是一种解释器，它使用解释器宿主语言的类似设施来定义解释语言的每个特征。例如，解释一个 lambda 应用程序可以使用函数应用程序来实现。
在 Lisp 的上下文中，我认为这意味着解释器实现将程序状态存储在与语法本身所表达的数据结构相似的数据结构中，即列表。
更一般地说，我会说解释器实现使用语法的范式来解释语法。此外，它与用解释语言实现的解释器无关（Lisp 解释器通常用 C 编写）。只有范式等效很重要。
让我们考虑 Java Maxine Virtual Machine，元循环 JVM。 Maxine JVM 是用 Java 编写的。它是在 JVM 中运行的 JVM。同样，解释器使用与解释语言相同的范式。 Java对象表达的可执行代码由Java对象表达的可执行代码管理。当然，实际的可执行文件是字节码，但它之外的抽象概念才是最重要的。因此，我相信 Maxine 可能是用任何语言编写的，并且仍然被视为元循环，只要实现符合 OOP 概念和 Java 规则。最明显的这种语言是 Java 本身。然而，这是我在上一段中描述的一个有趣的冲突，它真的让我很头疼！
这就是我在理论上理解元循环评估器的含义的方式。但我并没有真正了解实际方面。根据维基百科
与现有的语言实现相结合，元循环解释器提供了一个基线系统，可以通过添加更多特性向上扩展语言，或者通过编译掉特性而不是解释它们向下扩展
这实际上意味着什么？例如，这是如何使用 Maxine 虚拟机实现或可能付诸实践的？这与eval 等函数有何不同？
如果我们更哲学一点，元循环解释器有两个前提
- 解释器实现语言无关紧要，范式等价才重要
- 在执行级别，范式的概念不复存在，一切都只是字节
元循环的明确界限是什么？这个特性究竟体现在哪里？我可能想多了，但我觉得这是一个有趣的话题。
【问题讨论】：
-
我认为您在这里忽略了重点。如果我用 Java 为 Java 编写一个完整的或几乎完整的解释器，那么它就符合条件。至于
eval，来自您链接的维基百科文章：“自我解释器显示相关语言的通用功能。” -
有趣的问题，但是 - 你能显示你的代码吗？并告诉我们您遇到的确切问题？就像现在一样 - 您的问题不适合 SO。
-
我想礼貌地反对 Jared。我自己的看法是，当语言的解析树与实际语言相同时，元循环评估器的魔力就会绽放。只有 LISP 家族语言才能做到这一点。
-
在 Lisp 中，元循环解释器是用 Lisp 本身编写的。用 C 编写的 Lisp 解释器不是元循环的。 Lisp 解释器执行 Lisp 源代码，而不是字节码或类似代码。一般来说，它更多的是一个理论/教学概念，因为大多数实用的 Lisp 解释器都不是元循环的。虽然有人可能会使用 Lisp 编译器来创建 Lisp 解释器。
-
考虑语言 x' 的两个评估器，用与 x' 相似的某种语言 x 编写，并且可能与它相同。在其中之一中，x' 中的函数调用由 x 中的函数调用实现，依此类推。另一方面，有一个用于 x' 的编译器将其编译为 x86 机器代码，以及一个用于 x86 的仿真器，用 x 编写，运行此代码，从而生成 x 的求值器。其中一个是元环，另一个不是。
标签： functional-programming lisp eval metacircular