[Anthy-dev 2696] Re: r5rs: コード再編

アーカイブの一覧に戻る

YamaKen yamak****@bp*****
2005年 12月 13日 (火) 06:10:33 JST


ヤマケンっす。

おおむね賛成してもらえたみたいなんで、まずは今後作業する分から適
用していきましょう。全体的なrenamingや整形は最後にするつもりです。

At Tue, 13 Dec 2005 00:56:30 +0900,
mover****@hct***** wrote:
> >   - prefix整理

> >     * SigScm_, Scm_, scm_ -> scm_    (関数、変数とも)
> >     * ScmOp_              -> scm_p_  (procedure)
> >     * ScmExp_             -> scm_s_  (syntax)
> 賛成。Cから呼び出す関数にはscm_c_を付けたいです。例えばrequire
> の様にcとscmの両方から呼び出される場合はscm_c_requireや
> scm_requireの様にして区別したいです。

それは逆では。

以下のようにSchemeと共用する(= procedureやsyntaxとして登録される)
関数の側を特別扱いするべきです。

int scm_require(const char *filename);
ScmObj scm_p_require(ScmObj filename);

そうした方がいい理由は、

  ・引数や返値がScmObjであると注意を喚起する

  ・引数の評価/as-isを対象関数の知識なしに判別するためprocedure
    かsyntaxかを明示するのが望ましい

  ・'c_' prefixでは付く/付かないの規則性が不明瞭で混乱する

もしかしたら上記のscm_p_require()をscm_c_require()と呼びたいのか
もしれませんが、上述のようにproc/syntaxは区別した方がいいです。

> >   - 型名のprefixと命名規則はScmFooBarのまましばらく保留
> どうせならこの機に変えてしまっても良いと思います。

一度にやるのはやめときましょう。やるにしても、関数名を
underscore_separatedに変更してしばらく馴染んでからの方が調和の取
れた良い名前を考えられえると思います。

> > * ファイル再編
> >
> >   - debug.c -> print.c, error.c
> >
> >     実態に合わないので。debug_mask等の処理はerror.cに集約
> 賛成。また、Scm_malloc等は alloc.c に移動させたいです。strdup等も
> Scm_strdupを用意し、Object Compactionで必要な alignment を確保
> できるようにしたいです。

了解っす。alloc系以外の関数が加わった場合は再度改名を考えましょ
う。

> >   - sigschemetype*.h -> storage*.h
> >
> >     現在はsigscheme.hとsigschemetype.hに分かれているが、この「型
> >     関連かどうか」という線引きにはなんとなく綺麗になったような気
> >     がする整頓以上の意味はない。むしろsigschemetype{,-compact}.h
> >     の間で重複部分が発生して害になっている。[Anthy-dev 2304]で主
> >     張したようにstorage層の抽象化目的に徹すればこの問題は解決し、
> >     さらに以下のような利点が得られる。
> >
> >     * SigScm_nullやSCM_TAG_IMM_NULLP等、libsscmユーザが直接触れ
> >       るべきでないものをstorage*.hに隠蔽できる
> >
> >     * sigscheme.hだけ見ればlibsscmの全APIを安全に利用できる
> >
> >     * storage実装毎に異なるfreecell操作マクロの実体をstorage*.h
> >       に集約できる
> 良いっすねこれ。しかし、ただでさえ長いsigscheme.hがさらに長くなってしまう
> ので sigschemetype.h は残しておきたいかなぁと思います。gauche.hなんか
> は3k行も有って一目見ただけでは何がなんだか。ドキュメントを書けば良いと
> いう話も有りますが、限界が有るでしょう。

公開インタフェイスだけを移すんだからそんなに長くならないと思いま
すが、仮にそうでも問題ないんじゃないかなあ。むしろ1つのファイル
にまとまってた方がコメントやら定義やら整頓区分やら関係なく
isearchで飛びながらハイライトして確認できるので見やすいと思いま
すが。

どうしても短かくまとめたいという場合も、分離すべきはscm_{p,s}_* 
だと思います。これらはCでSigSchemeの関数を書いたりlibsscmを組み
込んだりする際に必須ではないし利用頻度も低いので。むしろ
configuration次第で非公開にしてしまってもいいぐらい。

とりあえずsigschemetype*.hには手を付けずにsigscheme.hに#if 0で囲っ
た定義を入れてみるので、それを見て判断してください。

At Mon, 12 Dec 2005 02:01:59 -0800,
jun.l****@gmail***** wrote:
> 
> YamaKen <yamak****@bp*****> writes:
> >   - マクロの引数名は以下のように
> >
> >     MACRO(x)       /* Cレベル操作 */
> >     SCM_OP(o)      /* object */
> >     SCM_EQ(a, b)   /* 2つ以上の対等object */
> 
> Public header に載せるものに限っては賛成。他では逆に不自由な思いをする
> だけだと思うので反対。

私もそのぐらいのつもりです。いい名前がある場合はこれに縛られずに。
恣意的な1文字名を選択する際のガイドラインと思ってください。

気になってたのはSCM_SYMBOLP(a)とかの'a'です。なんかbやcもあるよ
うな気がしちゃって。

-------------------------------
ヤマケン yamak****@bp*****



Anthy-dev メーリングリストの案内
アーカイブの一覧に戻る