Posted on 2008-11-02 01:18
dennis 閱讀(1823)
評論(0) 編輯 收藏 所屬分類:
計算機科學(xué)與基礎(chǔ)
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在沒有強迫求值前，僅僅執(zhí)行了一步(id 10)，因此此時count為1，當(dāng)要求打印w的時候force執(zhí)行了第二步(id 10)，因此count增加為2。
4.28，當(dāng)參數(shù)也是函數(shù)的時候，例如：
(define square (lambda(x) (* x x)))
(define (test proc a)
(proc a))
(test square 3)
如果對operator不采用actual-value，那么square將延時求值，在執(zhí)行(proc a)時無法辨認(rèn)eval的過程類型。
4.29，俺第一個想到的就是樹形遞歸的斐波那契數(shù)列：
(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出現(xiàn)了兩次，那么如果是使用不帶記憶功能的force-it， x將被求值兩次，如果x本身帶有副作用（例如例子里面的id過程），那么顯然副作用也將被調(diào)用兩次，因此答案不言自明。帶記憶功能的force-it版本中，count將仍然是1，而在不帶記憶功能的版本中count將增長到2。
4.30，第一問，我也談不出所以然為什么ben的說法是正確的，關(guān)注下第二問的兩個過程在不同eval-sequence下的表現(xiàn)，(p1 1)的結(jié)果沒有改變都是(1 2)，而(p2 1)在原始版本的eval-sequence中結(jié)果是1，而在Cy修改后的版本中(對中間步驟采用actual-value)結(jié)果是(1 2)，也就是說在原始版本中的(set! x (cons x '(2)))的副作用根本沒有實現(xiàn)，而在修改后的版本中實現(xiàn)了。俺覺的這個問題很迷惑，惰性求值與side effect相互作用很奇特，不過我更偏向原始版本，因為我覺的這樣的實現(xiàn)更容易看清代碼的意圖，也就是說在透明性上更好，例如我分析p2過程就可以認(rèn)為直接返回參數(shù)x；而實現(xiàn)副作用很容易讓人掉入陷阱，并且很可能引進(jìn)難以查找的bug。