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

Back to archive index

YamaKen yamak****@bp*****
2005年 12月 12日 (月) 16:07:56 JST


ヤマケンです。

r5rsブランチのマージに向けてSigSchemeのコード整理を行ってますが、
そろそろ全体的な再編を行いたくなってきました。以下に案を出してみ
たので意見聞かせてください。

以前引っ込めた案件も入ってますが、コードを書き進めるうちにやはり
必要だと感じたので再提案します。もう一度考えてみてください。

部分部分でいいので簡単なものから回答お願いします。議論の終わった
とこから先に進めときますんで。

* grand renaming

  - UpperCamelCaseな関数名をunderscore_separatedに統一

    * 現状ではglobal関数がUpperCamelCase、その他が
      underscore_separatedになっているがこのような使い分けは混乱
      を招くし見難い

    * 今でもstatic関数等はunderscore_separatedなので、この形式に
      馴染めないという事はありえないはず

    * UpperCamelCaseに統一という道もあるが、そうするとprocedure
      やsyntaxに直接対応する関数名がわかりにくく混乱する
      例: set-cdr! -> SetCdrD? SetCdrd?

  - prefix整理

    prefixがScm_, ScmOp_, ScmExp_のようにトップレベルで分かれて
    いると見難いし、libsscmがどこまで名前空間を予約しているのか
    一見さんに判別できない。Scm_のように単一のprefixを付けその中
    で分類した方がよい

    * SigScm_, Scm_, scm_ -> scm_    (関数、変数とも)
    * ScmOp_              -> scm_p_  (procedure)
    * ScmExp_             -> scm_s_  (syntax)

  - 型名のprefixと命名規則はScmFooBarのまましばらく保留

  - Schemeの慣習に従って new -> make に
    Scm_NewInt -> scm_make_int
    #define MAKE_INT(x) (scm_make_int(x))

  - MAKE_BOOLマクロ導入

    #define MAKE_BOOL(x) (scm_make_bool(x))

    return (EQ(a, b)) ? SCM_TRUE : SCM_FALSE;
             ↓
    return MAKE_BOOL(EQ(a, b));

  - MutableStringとImmutableStringはやはり片方だけ例外扱いすれば
    十分。逆に両方ともフルに修飾されているとわかりづらい。String 
    で暗黙にmutableなフル機能の文字列とし、ImmutableStringで制限
    をかけるというイメージでどうか

* coding style

  - 関数本体の定義では以下のように返値の型で改行する

    void
    foo(void)
    {

  - 変数は初期化せず型ごとに1行に集約する(長い場合は分割)

    理由は[Anthy-dev 2507]参照。それとSigSchemeではコードが太る
    のも避けたい

  - マクロの引数名は以下のように

    MACRO(x)       /* Cレベル操作 */
    SCM_OP(o)      /* object */
    SCM_EQ(a, b)   /* 2つ以上の対等object */

  - その他は保留。[Anthy-dev 2581]の議論を収束させてから

* ファイル再編

  - debug.c -> print.c, error.c

    実態に合わないので。debug_mask等の処理はerror.cに集約

  - 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:
    typedef ScmSalObj ScmObj;
    #define SCM_SYMBOLP(o)               SCM_SAL_SYMBOLP(o)
    #define SCM_ENTYPE_SYMBOL(o)         SCM_SAL_ENTYPE_SYMBOL(o)
    #define SCM_SYMBOL_NAME(o)           SCM_SAL_SYMBOL_NAME(o)
    #define SCM_SYMBOL_SET_NAME(o, name) SCM_SAL_SYMBOL_SET_NAME((o), (name))

    storage-fatty.h:
    typedef ScmCell *ScmSalObj;
    #define SCM_SAL_SYMBOLP(a)       (SCM_TYPE(a) == ScmSymbol)
    #define SCM_SAL_ENTYPE_SYMBOL(a) (SCM_ENTYPE((a), ScmSymbol))
    #define SCM_SAL_SYMBOL_NAME(a)   (SCM_AS_SYMBOL(a)->obj.symbol.sym_name)
    #define SCM_SAL_SYMBOL_SET_NAME(a, name)   (SCM_SYMBOL_NAME(a) = (name))

    storage-compact.h:
    typedef ScmCell *ScmSalObj;
    #define SCM_SAL_SYMBOLP(a)       (SCM_TAG_OTHERSP(a) && SCM_TAG_OTHERS_SYMBOLP(a))
    #define SCM_SAL_ENTYPE_SYMBOL(a) (SCM_ENTYPE_PRIMARY_TAG_OTHERS(a),  SCM_DO_UNMARK(a), SCM_SET_DIRECT_CDR((a), SCM_TAG_OTHERS_SYMBOL))
    #define SCM_SAL_SYMBOL_VCELL(a)  (SCM_CAR_GET_VALUE_AS_OBJ(SCM_AS_SYMBOL(a)))
    #define SCM_SAL_SYMBOL_NAME(a)   (SCM_CDR_GET_VALUE_AS_STR(SCM_AS_SYMBOL(a), ~SCM_TAG_OTHERS_MASK_SYMBOL))

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



Anthy-dev メーリングリストの案内
Back to archive index