关于线程的 MIT/GNU 方案参考在哪里？答案

【问题标题】：Where is the MIT/GNU scheme reference on threads?关于线程的 MIT/GNU 方案参考在哪里？
【发布时间】：2020-06-04 09:25:22
【问题描述】：

我看过这里 - reference。此外，查看了其他一些地方，但结果发现它们是其他方案方言，这意味着那里的功能不一定存在于 MIT/GNU 方案中。

我显然知道必须有线程相关的过程，因为像 create-thread 或 current-thread 或 thread-dead 这样的东西有效。任何人都可以指向线程的参考。我使用的是 MIT/GNU Scheme 9.2 版。

【问题讨论】：

标签： scheme lisp sicp mit-scheme

【解决方案1】：

为mit-scheme工作的志愿者并不多，一般都是MIT EECS的校友，在那里他们确切地了解了mit-scheme是如何实现的，并且是唯一有能力理解它的人；这就是为什么最好在mit-scheme-devel@gnu.org 提问，有人肯定会回答你一些具体问题。除了来自src/compiler/documentation 和here 的文档外，没有其他文档。

使用git log | less 并搜索thread 也不会返回任何提示。

Here 是唯一可用的文档，here 被问到同样的问题。他肯定收到了私人答复。

【讨论】：

FWIW 邮件线程中的问题与线程无关。 thunk 的定义是 (define (thunk x) (lambda () x))，这是不正确的。需要一个宏来实现thunk。
@soegaard 我不确定你在说什么，也许他将 x 作为 (lambda() something) 传递，并通过评估 thunk 他得到 x 作为另一个 thunk。不需要宏，但该邮件的重点是关于文档的不存在。
我的意思是 MIT Scheme 中的线程是有效的。链接到的帖子中的示例给人的印象是存在问题。问题是一个错误的测试。发帖人将thunk 定义为(define (thunk x) (lambda () x))，然后将其称为(thunk expr)，但错过了expr 的评估不会延迟。
@soegaard 确实，他对延迟操作是错误的，但通常延迟操作可以在没有宏的情况下实现，它可以 - 按照惯例 - 嵌套在一个 thunk 中并在它的值时强制执行是必需的，并且在不使用宏的情况下会发生这种情况。还有一种情况是惰性求值默认可用，根据需要进行求值。