YamaKen
yamak****@bp*****
2005年 9月 24日 (土) 17:02:54 JST
ヤマケンです。 At Thu, 22 Sep 2005 21:45:15 -0700, jun.l****@gmail***** wrote: > > On Fri, 23 Sep 2005 09:53:15 +0900 > YamaKen <yamak****@bp*****> wrote: > > - call()は単なる関数呼び出しというよりは、evalループの一部として > > 関数呼び出しフォーム全体のevalを担当しています。なので、名前も > > それを反映してeval_calling()とかeval_invocation()としてみては > > どうでしょうか。 > > 反対。call() は、apply と eval の共通部分を refactor したもので、eval の > 一部というのは不正確です。引数の評価が call に入っているのは > performance hack であって、本来の役割は関数の呼び出しです。 > 名前と実態が微妙にずれていて変だというのは分かりますが、そもそも切り分け > がうまく(でき)ないので、下手に名前で説明しようとしない方がいいと思いま > す。 では当面call()のままという事で。責任範囲もまだ変わるかもしれませ んしね。 > > - SCM_EVAL_STATE_NO_TAIL_RECは認識上SCM_EVAL_STATE_TAIL_RECと紛 > > らわしいのでSCM_EVAL_STATE_NESTとかにしてみませんか? > > 正直、"Nest" では意味が分かりません (私は何が言いたいのか予め知っている > からわかりますが)。かといって、NO_TAIL_REC のままにもしたくはありませ > ん。s/tail_flag/ret_type/g して、全体を短く、SCM_RET_TAIL と > SCM_RET_NOT_TAIL ではどうですか? あるいは SCM_RET_NEED_EVAL と > SCM_RET_LITERAL。 では"nest"はやめときましょう。 私の感覚だとSCM_RET_NEED_EVALがわかりやすいのでSCM_FUNCTYPE_等と 命名規則を揃えてSCM_RETTYPE_NEED_EVAL、さらに"literal"は書かれて ないものに対して使うのは違和感があるんで対にするのは SCM_RETTYPE_ASISなんてどうでしょう? 要はこれ以上加工するなという 事を示したいんですが。 > > * reduceまわり > > > > - 'SCM_BINARY_OPERATOR'は単発の二項演算のためのタイプと誤解され > > やすいので他の名前の方がいいと思います。いい名前が思い付きませ > > んが、とりあえず候補としてSCM_FUNCTYPE_REDUCER、 > > SCM_REDUCTION_OPERATOR、SCM_REDUCE_HANDLERあたりを > > これも悩みどころ…SCM_REDUCTION_OPERATOR でいきましょう。 > でも名前よりも、演算子側の interface はこれでいいんでしょうか。10% ずつ > ほど肥大化してて、もっといいやりかたがありそうなもんなんですが。 コードサイズがですか? 実行速度の方はresultをCの型のまま保持する 仕組みを加えれば少しは改善すると思いますが、SCM_REDUCE*()マクロ のような方法が採れない以上大枠としてはこうするしかないのでは。私 がSCM_REDUCE*()後に手元で書いてみたコードもこれに近いですし。 そもそもの動機だったコードの一元化・整理という目的は達成できてる ので、ひとまずこれでまとめてしまってよいと思います。 > > - reduce()はsupress_evalを受け取るようにしないとapplyやmapが正常 > > に動かないと思われます(これから手を付けるのかもしれませんが一 > > 応) > > 忘れてました。直します。 ではこれが終わったあたりでcommitする事にしましょう。 > > - define_comparator -> マクロなのでDEFINE_COMPARATORに > > 別にそれでいいんですが、後から commit までに手で展開するつもりですのであ > んまり気にしなくてもいいと思います。まだ reduce の interface に納得が > いってないから、いじるのが楽なようにマクロにしただけです。 > でもマクロのまま採用しようというならそれでもいいと思いますが。 マクロで一元化したままの方がバグが入らなくてよいと思います。まあ 関数定義の外枠だけは展開しておいた方がツール類にも人間にも優しい とは思いますが。 ------------------------------- ヤマケン yamak****@bp*****
