SICP 読み (169) 4.1.6 内部定義
このエントリは晩メシ食わないでアルコールが入った状態で書いてますので、信頼性はナニ。(を
ちょっとこのあたりの問題は微妙にミクロでストレスたまります。なつたんさんトコでスルーされてるのは正解じゃないかなと思ってしまいつつも、手が「スルー」と入力するのを止めてたりそうでなかったり。(何
とりあえず問題 4.16 の c な解は見出せてないまんまで次も微妙。
問題 4.17
環境の図を云々はスルー。次に、_余計なフレームがあるのはなぜか_との問いですが、
(lambda <vars> (let ((u '*unassigned*) (v '*unassigned*)) (set! u <e1>) (set! u <e2>) <e3>))
にある let なリストは eval によって以下の手続きに変換されます。
((lambda (u v) (set! u <e1>) (set! v <e2>) <e3>) '*unassigned* '*unassigned*)
この式は apply により '(u v) に '(*unassigned* *unassigned) を束縛した新たな環境で中身の式が順に eval されていきます。これが上記で言う_余計なフレーム_なのでしょうか。
ちなみに以下の場合
(lambda <vars> (define u <e1>) (define v <e2>) <e3>)
vars を束縛しているナニは上記の余計なフレームからも参照可能ですので、プログラムの挙動には何も影響はない、と言うと言い過ぎかなぁ。一つ上のフレームを見に行かないと、という手間はあるでしょうが。
で、余計なフレームを構成したくない、と言うのであれば乱暴かもしれませんが、let ではなく define 使って「掃き出し」を行なうしか無いように思えます。
ちなみにぱっと見で extend-environment すりゃええじゃん、と思ってしまったのですが、これでは余計なフレームを作ってしまってて駄目。
追記
内容的なハードルが上がってるのか、個人的なソレが微妙なのか分からんが微妙なナニを自分でも意識できています。もう少し丁寧な方が良いのか、逆が良いのかどうなのか。
なんかグタグタで微妙。(とほほほ