SICP书籍描述了如何在Scheme中实现Scheme解释器。我已经玩了好几个月了，我的代码已经从书中发展而来了。我现在已经达到了实施strict-eval程序的阶段，我正在尝试实施一个lazy-eval对手，它始终会返回一个＆＃39; thunk＆＃39; （一些对象封装表达式和环境以及memoization信息）。我有一个force-thunk过程，用memoization评估thunk。我的快速和脏实现当前返回围绕set!表达式的thunk包装器，当然这会导致奇怪的语义（在强制thunk之前不会发生副作用）。我很想改变这一点，并且lazy-eval程序对set!表达式严格。实际上，更确切地说，我正在考虑推迟对所分配的表达式的评估（因此从中创建一个thunk），但不会延迟绑定的更改（即，立即将符号分配给环境中的新thunk）。我有什么理由选择延迟副作用吗？
答案 0 :(得分：1)
set!改变绑定并将参与者从引用透明变为必须处理不断变化的世界。我认为我同意你的描述，绑定应该与新的thunk而不是旧的thunk相关联，因此绑定不是设置为懒惰但它的值仍然是懒惰的。
(define x expression) ; ==> x is a thunk
(set! x (+ x x) ; ==> x is a new thunk that references the old `x`
(display x) ; display would force the evaluation of the nested thunks referenced by `x`
如果你延迟了实际的绑定阶段，那么上面的代码永远不会强制从set! - 表达式返回的值，因为它永远不会被使用，因此x将是强制进入的旧thunk display？