SICP 読み (184) 4.2.2 遅延評価の解釈系
5 章はボーナスステージらしい。楽しみなんですが先はまだまだ長い。ってか scheme なソレを開始したのが昨年末で一応は一年というシバリを、だったんですが果たして一年で終了するんだろうか、という心配はまだまだ早いか。
問題 4.28
演算子を actual-value しなければならない理由としては、thunk かもしれないという可能性があるから、なんだろうなと。これまで出てきたナニでは thunk になる (delay-it される) のは compound-procedure の引数のみ。
ちなみに actual-value が使われるケイスとしては
- apply に渡された式の operator
- if の条件式
- 解釈系に渡された式
のみ、な模様。ちなみに演算子 (というか operator) が thunk であるケイスとしては
((lambda (op n) (op 5 n)) ((lambda (p) p) *) 5)
みたいなソレでしょうか。
上記を手動で評価してみますと、まず上記の式は application 認定。env はナニ。
(apply (actual-value (lambda (op n) (op 5 n))) (((lambda (p) p) *) 5) env)
演算子は thunk でないのでそのまま eval されるから以下。
(apply (procedure (op n) ((op 5 n)) env) (((lambda (p) p) *) 5) env)
上記は compound-procedure 認定で以下。
(eval-sequence ((op 5 n)) (extend-environment (op n) (list-of-delayed-args (((lambda (p) p) *) 5)) env))
なんか適当に進めてる感満点ですが、そのままスルー。(これが微妙な所以
引数に束縛されるナニを評価しないと駄目ですね。評価したら以下のナニになるはず。
(eval-sequence ((op 5 n)) (extend-environment (op n) ((thunk ((lambda (p) p) *) env) (thunk 5 env)) env))
で、eval-sequence な手続きを順に適用。順に eval してけば良いのかな。
(eval (op 5 n) (extend-environment (op n) ((thunk ((lambda (p) p) *) env) (thunk 5 env)) env))
op も n も actual-value しないと束縛が解決不能。特に op は、という事ですか。ちなみに (op 5 n) は application 認定なので以下。ちなみに評価される環境は上記の通り、拡張されたフレームになる。面倒なので env と書きますが、ここは押さえが必要。
(let ((nenv (extend-environment (op n) ((thunk ((lambda (p) p) *) env) (thunk 5 env)) env))) (apply (actual-value op nenv) (5 n) nenv))
op には (thunk ((lambda (p) p) *) env) が束縛されているし、n には (thunk 5 env) が束縛されている、はず。えーと、問題のポイントとしてはここなのかなぁ。昨晩のようなボケをぶちカマさないように、一旦ここでネカせてみます。
ここ以前に勘違いがあったら目も当てられないのですが。