方案R7RS中负载和包含之间的差异

Question

在Scheme R7RS中，有一个load和include表单。

其中包括：

语义:包括和包含-ci都采用一个或多个文件名表示为字符串文字，应用一个特定于实现的算法来查找相应的文件，按照指定的顺序读取文件的内容，就像重复应用read一样，并有效地用包含从文件中读取的内容的开始表达式重新放置包含或包含-ci表达式。两者的不同之处在于，include-ci读取每个文件，就好像它以#！折叠大小写指令开头一样，而include则不这样做。注意:我们鼓励实现在包含包含文件的目录中搜索文件，并为用户指定要搜索的其他目录提供一种方法。

负载描述为：

依赖于实现的操作用于将文件名转换为现有文件保存方案源代码的名称。load过程从文件中读取表达式和定义，并在由环境说明符指定的环境中对它们进行顺序化。如果省略了环境说明符，则假定(交互-环境)。未具体说明是否打印了表达式的结果。加载过程不影响当前输入端口和当前输出端口返回的值。它返回一个未指定的值。基本原理:为了便于移植，加载必须对源文件进行操作。它对其他类型文件的操作必然因实现而异。

这两种形式的理由是什么？我想这是历史性的。这两种形式之间有什么重要的语义区别吗？我看到load可以选择性地包括一个环境说明符，而include没有这个功能。而include-ci没有直接等价的使用load。但是，仅仅比较load和include，有什么不同，它是否重要？

Answer 1

我认为关键的区别在于，include是语法(或者在传统的Lisp术语中，它是宏)，而load是一个函数。在传统的Lisp术语中(我不能给出更正式的定义)，这意味着include在宏扩展时工作，而load在评估时完成它的工作。对于具有文件编译器的实现来说，这些时间可能是非常不同的:宏扩展时间发生在文件的编译过程中，而计算只在加载编译后的文件时才发生。

因此，如果我们考虑两个文件，f1.scm包含

(define foo 1)
(include "f2.scm")

和含有f2.scm的

(define bar 2)

然后，如果加载或编译f1.scm，则与加载或编译包含以下内容的文件fe.scm完全相同：

(define foo 1)
(begin
  (define bar 2))

这与fe.scm包含的内容相同：

(define foo 1)
(define bar 2)

特别是，这种文件的包含发生在宏扩展时，这发生在编译器运行时:编译器生成的对象文件(fasl文件)将包括foo和bar的编译定义，并且在任何方面都不依赖于f2.scm或其编译后的等效的存在。

现在考虑f3.scm，它包含：

(define foo 1)
(load "f2")

(注意，我假设(load "f2") (相对于(load "f2.scm"))加载编译后的文件，如果它能找到它，那么加载源文件:我认为这是依赖于实现的)。

加载此文件的源将执行与加载f1.scm相同的操作:它将导致定义foo和bar。但是编译这个文件不会:它将生成一个编译过的文件，在以后加载它时，它将尝试加载f2.scm的源代码或编译版本。如果该文件存在，则将在加载时加载该文件，其效果将与include大小写相同。如果它在加载时不存在，那么坏的事情就会发生。编译f1.scm不会导致编译f2.scm中的定义。

根据你的背景，这可能是值得比较的，比如说，C-家庭语言。include所做的是#include所做的工作:它在读取源文件时将它们连接起来，在C中(就像在许多Scheme/Lisp系统中一样)，这是在编译文件时发生的。load所做的是在运行时加载代码，在C中，您需要调用动态链接器或其他方法来完成这些工作。

Answer 2

过去，Lisp实现不提供模块系统。

大型程序使用 load 来运行一组指令，load函数通过逐个读取文件中的S-表达式并将它们传递给eval来运行REPL脚本。

另一方面，包含用于将从文件中读取的代码内联到您的代码中。It 不计算代码.

...replace包含或包含-ci表达式，其中包含从文件中读取的内容。

添加的“begin”准备从要按顺序计算的文件中读取的代码。

资料来源:问题引号，球拍文档