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) が束縛されている、はず。えーと、問題のポイントとしてはここなのかなぁ。昨晩のようなボケをぶちカマさないように、一旦ここでネカせてみます。
ここ以前に勘違いがあったら目も当てられないのですが。