Jun Inoue
jun.l****@gmail*****
2005年 9月 24日 (土) 17:45:48 JST
On Sat, 24 Sep 2005 17:02:54 +0900 YamaKen <yamak****@bp*****> wrote: > 私の感覚だとSCM_RET_NEED_EVALがわかりやすいのでSCM_FUNCTYPE_等と > 命名規則を揃えてSCM_RETTYPE_NEED_EVAL、さらに"literal"は書かれて > ないものに対して使うのは違和感があるんで対にするのは > SCM_RETTYPE_ASISなんてどうでしょう? 要はこれ以上加工するなという > 事を示したいんですが。 最初は AS_IS って書いて後で消したんですが、今思うとこっちの方がよさげで すね。NEED_EVAL / AS_IS で。 > > これも悩みどころ…SCM_REDUCTION_OPERATOR でいきましょう。 > > でも名前よりも、演算子側の interface はこれでいいんでしょうか。10% ずつ > > ほど肥大化してて、もっといいやりかたがありそうなもんなんですが。 > > コードサイズがですか? 実行速度の方はresultをCの型のまま保持する > 仕組みを加えれば少しは改善すると思いますが、SCM_REDUCE*()マクロ > のような方法が採れない以上大枠としてはこうするしかないのでは。私 > がSCM_REDUCE*()後に手元で書いてみたコードもこれに近いですし。 > > そもそもの動機だったコードの一元化・整理という目的は達成できてる > ので、ひとまずこれでまとめてしまってよいと思います。 そう、コードサイズが 10% 増。まぁでも byte 数にすれば大した差ではないの で目をつむる事にします。 result を C のまま保持、というのも考えているんですが、静的変数を使うか引 数を multiplex するか他にあるか、と考え中なので今回は見送ります。 > > > - reduce()はsupress_evalを受け取るようにしないとapplyやmapが正常 > > > に動かないと思われます(これから手を付けるのかもしれませんが一 > > > 応) > > > > 忘れてました。直します。 > > ではこれが終わったあたりでcommitする事にしましょう。 そうしましょう。(write (values)) の fix も持ってますし。 > > > - define_comparator -> マクロなのでDEFINE_COMPARATORに > > > > 別にそれでいいんですが、後から commit までに手で展開するつもりですのであ > > んまり気にしなくてもいいと思います。まだ reduce の interface に納得が > > いってないから、いじるのが楽なようにマクロにしただけです。 > > でもマクロのまま採用しようというならそれでもいいと思いますが。 > > マクロで一元化したままの方がバグが入らなくてよいと思います。まあ > 関数定義の外枠だけは展開しておいた方がツール類にも人間にも優しい > とは思いますが。 これもそうします。明日は予定があるので明後日まで待たれよ。 -- Jun Inoue jun.l****@gmail*****
