Reflection R7RS方案的反射能力

关于编程语言方案的R7RS报告描述了在方案系统中运行方案代码的两种方式：

1） 方案系统可以运行报告第5.1节所述的程序

2） scheme系统可以提供一个read-eval打印循环，在该循环中，scheme代码以交互方式进行解释

我的问题是如何在R7RS报告中包含的Scheme系统中反映这两种运行Scheme代码的方法

有一个eval库过程

eval

，它在运行的Scheme系统中执行Scheme代码，因此

eval

看起来就像我正在搜索的

但是，我可以插入的唯一保证可变环境是

eval

交互环境repl库过程返回的环境。但是，使用这种方法，我无法可靠地模拟REPL（上面的第2点），因为REPL允许导入表单，

eval

过程不必这样做

此外，由于其他原因，我无法使用交互环境来评估完整的方案程序：它通常不是空的，特别是它包含

（方案库）

的所有绑定

为了在运行的方案系统内实现1），eval library过程

environment

看起来很有希望，因为它允许预先导入库（这是运行程序的一部分）。但是，环境是不可变的，因此我无法在环境中计算

define

s。一种解决方法是将要运行的程序主体包装成

lambda

形式，以便

define

定义局部变量。但是，这也不起作用：在

lambda

表单中，所有定义都必须位于主体的开头（这对于Scheme程序的顶层来说是不正确的），而在

lambda

表单库中，绑定可以被词汇覆盖，这是顶级绑定无法实现的

---

由于Scheme是图灵完成的，我当然可以在运行的Scheme系统中模拟Scheme系统，但我想知道，仅仅使用

eval

过程是否可行。我感兴趣的一个原因是，

eval

可能会得到优化（例如，通过JIT编译器后端），因此使用此过程可能会获得接近本机的速度（与手工编写简单的解释器相比）

R7RS small不适用于这种反射式实现。R7RS large将提供一个支持用户创建的可变环境的库。

import

声明可以以特定于实现的方式转换为等效的

load

。您还可以

加载一个包含用户输入的REPL表达式的文件。就个人而言，我会尝试直接
评估
导入
声明，但正如您所说，这不是完全可移植的，而且很可能什么都不是。我想repl通常是特定于实现的，这是有原因的。（披露：）