Jun Inoue
jun.l****@gmail*****
2005年 9月 23日 (金) 13:45:15 JST
On Fri, 23 Sep 2005 09:53:15 +0900 YamaKen <yamak****@bp*****> wrote: > 一通り変更点を確認してみました。非常に見通しの良いコードに生まれ > 変わっていてすばらしいです。井上さん、おつかれさまでした。 > > 以下に要望を挙げておきますが、基本的な仕組みには全く不満は無いの > で太田さんさえ良ければ一旦井上さんの区切りのいいところでcommitさ > せてもらいたいと思います。井上さんのアカウントがすぐ発行されるか > 太田さんが確認の上commitする時間が取れればそれにこした事はないで > すが、そうでなければ私がやっておきます。 Commit よりは review 用に投稿したんですが、今のまま commit しても別に問 題は無いので、ヤマケンさんが時間を取れるんでしたら、commit してください。 > - 関数呼び出しを指す用語として'invoke'と'call'が混在してますが、 > 妙な誤解の元になるので統一した方がいいと思います。Scheme的には > 'call'の方がいいんじゃないでしょうか 迷った跡です。:-) call にしましょう。 > - call()は単なる関数呼び出しというよりは、evalループの一部として > 関数呼び出しフォーム全体のevalを担当しています。なので、名前も > それを反映してeval_calling()とかeval_invocation()としてみては > どうでしょうか。R5RSによると()で囲まれた呼び出しフォームの事は > combinationと呼ぶそうですが、この名前では他のコードとの関連性 > が示しづらそうです 反対。call() は、apply と eval の共通部分を refactor したもので、eval の 一部というのは不正確です。引数の評価が call に入っているのは performance hack であって、本来の役割は関数の呼び出しです。 名前と実態が微妙にずれていて変だというのは分かりますが、そもそも切り分け がうまく(でき)ないので、下手に名前で説明しようとしない方がいいと思いま す。 > - 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。 > * reduceまわり > > - 'SCM_BINARY_OPERATOR'は単発の二項演算のためのタイプと誤解され > やすいので他の名前の方がいいと思います。いい名前が思い付きませ > んが、とりあえず候補としてSCM_FUNCTYPE_REDUCER、 > SCM_REDUCTION_OPERATOR、SCM_REDUCE_HANDLERあたりを これも悩みどころ…SCM_REDUCTION_OPERATOR でいきましょう。 でも名前よりも、演算子側の interface はこれでいいんでしょうか。10% ずつ ほど肥大化してて、もっといいやりかたがありそうなもんなんですが。 > - reduce()はsupress_evalを受け取るようにしないとapplyやmapが正常 > に動かないと思われます(これから手を付けるのかもしれませんが一 > 応) 忘れてました。直します。 > - define_comparator -> マクロなのでDEFINE_COMPARATORに 別にそれでいいんですが、後から commit までに手で展開するつもりですのであ んまり気にしなくてもいいと思います。まだ reduce の interface に納得が いってないから、いじるのが楽なようにマクロにしただけです。 でもマクロのまま採用しようというならそれでもいいと思いますが。 > * その他 > > - ScmOp_siod_eql()は必要です。SIODの=は(= foo 'sym)等の比較も可 > 能ですがR5RSは数値のみ …忘れてました; > - sigscheme.c: RFC: Should we implement these as type-checking > macros that directly call Scm_RegisterFunc()? > > No. 現在の形の方が不正形式の関数が入り込む隙が無くて良いです。 > コードサイズも条件次第でマクロの場合より小さくできると思います ではその方向で。 > - Scm_RegisterFunc()の第2・第3引数を入れ替えたい > Scm_RegisterProcedure*()等との整合性、及び引数中継コードの最適 > 化のため。IA32で実測 4バイト/1関数 減少 同じような事を RFC で書こうと思ってて失念してました…多いなそういうの。 これもそうしましょう。 -- Jun Inoue jun.l****@gmail*****
