Jun Inoue
jun.l****@gmail*****
2006年 4月 20日 (木) 10:36:14 JST
YamaKen <yamak****@bp*****> writes: > At Tue, 18 Apr 2006 16:52:37 -0700, > jun.l****@gmail***** wrote: >> >> (2) 関連部分が散らばっている >> >> [...] >> >> -構造体を追加 >> >> -検索+移動 >> >> -MAKE_* を追加 >> >> -検索+移動 >> >> -Accessor を追加 >> > >> > 実験段階ならここらあたりで適当に端折っとくのがいいと思います。 > [...] > その問題はインタフェイス自体を新設する試行錯誤の段階で起こるのだ > から、以下のような4層にまたがった変更を律義に行う代わりに、 > > 内部エイリアス MAKE_HYGIENIC_MACRO sigschemeinternal.h > 公開インタフェイス SCM_MAKE_HYGIENIC_MACRO sigscheme.h > SAL SCM_SAL_MAKE_HYGIENIC_MACRO storage-foo.h > 実装 scm_make_hygienic_macro他 storage-foo.h, storage*.c > > 一番外側のインタフェイスに合わせて直接実装を書いて実験を進めれば > ファイル間の移動を無くせるんじゃないかという話です。 > > 実装 MAKE_HYGIENIC_MACRO storage-foo.h > > inline関数を例に出したのは、プロトタイプと関数本体を分ける事なく > 他のマクロ定義と同じ場所に実装を集約できる事と、インタフェイスが > 確定してレイヤを分ける時にscm_make_hygienic_macro()等に実装をそ > のまま流用できるという事を示したかっただけです。当然マクロで書い > てあっても構いません。 > > SAL APIが確定した後は、新たなstorageを実装する際にいじる必要のあ > るファイルはstorage-foo.hとstorage*.cに限定されます。 「後で」は破滅の recipe なのでなるべく使わないことにしています。元の投 稿で一緒くたにしてしまったのがまずかったんですが、私は *問題にしている * のは同一層がバラバラに置かれている (構造体-MAKE-Accessor) せいで見通 しが悪い事で、層が多い事についてはまあ面倒臭いだけで、我儘に近いという ことはわかってます。 SAL_ 以外の層については不可欠だとも思ってますし、一度追加してしまえば 殆ど変更しないし M-. で飛べるし、層同士の分離もうまくいってるので別の 層を見ながら弄る必要も対してありません。SAL_ については後述の通り誤解 があったので文句垂れましたが撤回します。 > a storageが実装するべきインタフェイスのsetとその引数の名前・数を > 正確に規定できます。全て_SALプリフィクス付きなので各種スクリプト > 加工(例えばドキュメント生成)にも便利です。ちょっと面倒だけど静的 > 引数型チェックも仕込めるでしょう。各種デバッグ・計測用コードを埋 > め込むエントリポイントとして利用する事もできます。それから後述の > grepによる境界面の検出も捨て難いです。 最初についてはあまり積極的に賛成しませんが (やっぱり大差ない) それ以外 については納得しました。型 check については compact.h の misc でちょっ とやってみたんですが、「つけるならもう一つ上の層だよな」と思って消した 経緯があるので好都合です。 SAL_ はもっと ad-hoc なもので (隠蔽+αと実の無い念入れぐらい) 正直そこ までやるつもりがあると思ってなかったので、無い方がいいぐらいに考えたん ですが、もっと正しく使うなら色々使いでがありますね。内部用の prefix 無 し版の自動生成とかも。それとなーなーになってる部分が仕様ではないとわかっ たのですっきりしました。API と文書のくだりや SCM_MAKE_HYGIENIC_MACRO() の引数欠如についても、厳密に公開/非公開にあわせて境界を区切る気が無い ものと思い込んでたためです。 というわけで撤回します。 > SCM_ENTYPE()はfatty固有のマクロですが、公開APIに見えてもおかしく > ありません。やはり機械的に判別できる必要があると思います。 ではやはり ENTYPE は SAL_ から降格ということで。 ;; これが SAL_ になってたのは仕様だと思ってました。 ;; ていうか VALUECONS 周りで使われてるんですが。 > なるほど。動機はわかりました。でもその目的ならFIN()をSALのインタ > フェイスにまで格上げする必要はないと思います。compact独自の内部 > インタフェイスとしてFIN()を作るか、compact用のfree_cell()では内 > 部表現に直接触るかすればいいと思います。 内部表現の実装と直接操作を離れた箇所に置きたくないので前者にしましょう。 >> > 私からの希望としては、[Anthy-dev 2532]とstorage-compact.hの >> > SCM_INT_MSB付近のコメントに書いたように、元の実装ではstringや >> > vectorのlengthがintegerより無駄に広かったり符号ビットが未使用だっ >> > たりすところを最適化して欲しいです。 >> >> えーっと、MSB を mutable flag にするという話ですか。(Integer より広い >> というのはよくわかりませんが…。Integer は 32-4 bits, string / >> vector-length も mutable flag を考えると 32-4 bits でピッタリ合います。) > > lengthは常に非負なので、integerをそのまま格納可能なビット幅を > length向けに確保すると符号ビット分が無駄になります。 ぬぁ、integer の符号忘れてたorz > この1ビットを削ればtype encodingにだいぶ余裕がでるんじゃないかと > 思っての提案です。 1 bit か…難しいな。STRING と VECTOR の L1 tag を同一にしてそれの一つ 上の bit で識別するようにする…とか? Level の概念で対応しきれなくなり ますが (元々あんまり長続きするとは思ってないけど)。そうやって 3-bit tag を一つ空けると far symbol の tag を 3 bit にして、*un*hygienic macro 有効時に任意の env を保存する cost が安くなるので、ほんのちょっ とだけウマー…とか…。意味薄そうな気も。
