4.27，
;;; L-Eval input:
(define count 0)
;;; L-Eval value:
ok
;;; L-Eval input:
(define (id x)
(set! count (+ 1 count))
x)
;;; L-Eval value:
ok
;;; L-Eval input:
(define w (id (id 10)))
;;; L-Eval value:
ok
;;; L-Eval input:
count
;;; L-Eval value:
1
;;; L-Eval input:
w
;;; L-Eval value:
10
;;; L-Eval input:
count
;;; L-Eval value:
2
至于原因，w在没有强迫求值前，仅仅执行了一步(id 10)，因此此时count为1，当要求打印w的时候force执行了第二步(id 10)，因此count增加为2。
4.28，当参数也是函数的时候，例如：
(define square (lambda(x) (* x x)))
(define (test proc a)
(proc a))
(test square 3)
如果对operator不采用actual-value，那么square将延时求值，在执行(proc a)时无法辨认eval的过程类型。
4.29，俺第一个想到的就是树形递归的斐波那契数列：
(define (fib n)
(cond ((= 0 n) 0)
((= 1 n) 1)
(else
(+ (fib (- n 1)) (fib (- n 2))))))
不带记忆功能和带记忆功能的force-it之间的性能差距非常明显。
第二问，有趣的地方在于square过程，注意到(define (square x) (* x x))，x在body出现了两次，那么如果是使用不带记忆功能的force-it， x将被求值两次，如果x本身带有副作用（例如例子里面的id过程），那么显然副作用也将被调用两次，因此答案不言自明。带记忆功能的force-it版本中，count将仍然是1，而在不带记忆功能的版本中count将增长到2。
4.30，第一问，我也谈不出所以然为什么ben的说法是正确的，关注下第二问的两个过程在不同eval-sequence下的表现，(p1 1)的结果没有改变都是(1 2)，而(p2 1)在原始版本的eval-sequence中结果是1，而在Cy修改后的版本中(对中间步骤采用actual-value)结果是(1 2)，也就是说在原始版本中的(set! x (cons x '(2)))的副作用根本没有实现，而在修改后的版本中实现了。俺觉的这个问题很迷惑，惰性求值与side effect相互作用很奇特，不过我更偏向原始版本，因为我觉的这样的实现更容易看清代码的意图，也就是说在透明性上更好，例如我分析p2过程就可以认为直接返回参数x；而实现副作用很容易让人掉入陷阱，并且很可能引进难以查找的bug。
文章转自庄周梦蝶 ，原文发布时间2008-11-02