SICP 読み (379) 5.5 翻訳系
PAIR AND LIST の部分まで行きついて手が止まる。ってか何がしたいんだったっけ??とゆー世界だったり (何
問題 5.51
うーん。このまま進むと gauche-0.1 になる。gauche.h で定義されているデータ構造とゆーかマクロは流用させて頂きたいとは思うんですが、基本的には compile な手続きで C な命令列が出力される、というのがこの問題的なゴールのはず。
あ、違うや。インタプリタを書くのか。とほほほ。5.4 節の ch5-eceval.scm が C で書いてあれば良い、んだっけ。(駄目
少々の時間経過で若干冷静に
なんとなく思い出してきた。多分またワケワカらなくなるはずなんできちんと整理しとかんと駄目だ。と言いつつ頭がこんがらがってワケワカ状態に。以下は微妙なメモ
- レジスタ (というかグローバル変数か) 必要??
- apply できればなんとかなるの??
- とりあえず goto の事は考えまい
- でも compile -> assemble みたいに中間形式にできたら stack 的に楽
- ScmObj とそれを使う C な primitive 作ればなんとか
- read 非常にハードル高そげ
gc は別で、という事にしておいてこれでなんとかなるのかなぁ。別途時間を見つけてもう少し検討してみたい。
続
引き続きメモを箇条書き
- ええと、env は必要。jmp するワケじゃないから continue とか stack も不要なのだろうか。あとはローカル変数としての ScmObj なポインタで何とかなるのかなぁ。
- 関数ポインタでなんたら、と考えてたんですが引数の数が手続きによって異なるじゃん。(apply p l) な C の手続きを書かんとイケマセンか。あら??だんだんアタマがこんがらがってきた。なんなんだ。
- (apply p l) だと引数は eval して渡さんと駄目だからどっちにしても内部用の apply は手続きと引数リストを受けとる形にせざるを得ない? てーコトは primitive な手続きは ScmObj なリストを一つ受け取る形で統一しないと駄目なの?
- c の UT なツールって linux にあるのでしょうか (探す
随分冷静になれてきた。よく考えたら C の中でリストが使えりゃなんとかなるのか。gauche.h 万歳。(って何
一応ヒントは gauche.h だけってコトにして何とかしてみたいな、と。
- 手続きは内部向けのものと primitive なソレの切り分けしといた方が良さげ。apply の対象じゃなくっても引数はリストいっこ限定、にしといた方が良い?
