Jun Inoue
jun.l****@gmail*****
2005年 8月 19日 (金) 14:24:13 JST
On Thu, 18 Aug 2005 19:19:08 +0900 Kazuki Ohta <mover****@hct*****> wrote: > 僕も完璧に多値のセマンティクスを理解していないのですが、とりあえずtest caseが通るよ > うならそれで良いのでは無いでしょうか。 じゃぁそういうことで receive も書きました。extend_environment が外から呼 べないので回りくどい事をしてますが、env 関係の関数は static にするべきか 公開するべきか。とりあえず変更しませんでしたが。 でもマクロ実装してそれで作った方が良いかも知れませんね、こういう構文糖衣は。 > 色々考えている内にもう少し色々な型が欲しくなって参りまして... > > ScmObj ScmOp_quote(ScmObj obj) > > の様に、quoteにはenvが付かないようにしたいのですよね。逆にdefineではenvが必須です > し。なのでUNEVALED_ARGをまた分割するかもしれません。しかし、こうしているとキリが無 > いので、おとなしく歴史に従った方が良いのかも... 種類を増やす方針は固まったんだから、名前は適当に決めちゃって種類も適当に 多めに選んで、コード書いた方がいいと思います。それで後から名前をゆっくり 検討したり、該当関数が 1 つや 2 つしか無い型を粛清したりした方が多分生産 的でしょう。(多分 siod と同じようなセットに落ち着きそうな予感がしますが) ;; ちなみに私はヤマケンさんの RAW がちょっと気に入りました。でも ARGS よ ;; りは LIST のほうが良いと思います。FUNCTYPE0-5 からの類推で「引数に関 ;; する情報である」事は名前に含める必要は感じないので。 ;; でもひとまずは適当に決めたらいいと思います。 型名は初期化と eval でしか使わないので変な名前でもどうにでもなりますが、 型そのものが無い今の状況は早めに改善した方がいいと思います。該当関数の少 ない型を削るときの変更は少なくて済みますが、call-with-values やら receive みたいな、「他の型の方が自然に書けるけど無いからFUNCTYPE_R」とい うのが増えると、これを後から全部直して回るのは大変ですので。 -- Jun Inoue jun0****@users*****
