Kazuki Ohta
mover****@hct*****
2005年 12月 16日 (金) 13:29:27 JST
太田です。 > > > まず最初に、'tag'という用語の位置付けが私と食い違っているようで > > > す。以下のマクロ等で使われている'TAG_VALUE'という語は何を指して > > > いますか? > > > > 'tagの上位bitを占めているvalue'という意味ですが、分かり辛いですね。 > > やっぱりtagの指してるものが食い違ってるような気がします。 > > 私のコードでは以下のような構造を前提に名前を付けてあります。 > > VVVVVVVVVVVVVVVVVVVVVVVVVVVVVPPG > VVVVVVVVVVVVVVVVVVVVVVVVVVSSSPPG > VVVVVVVVVVVVVVVVVVVVVVVVVVEEEEEG > CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC > 31 0 > > G = GC bit (always 1 for others cdr) > P = primary tag > S = subtag > E = extended tag (S | P) > V = value > C = others cdr (V | tag | G) > > tag = (P == EXT) ? E : P; > > 'tag'という名前は、それがprimaryかextendedかに関係なく型情報の入っ > ているフィールド全体を指すものとして使っています。 > > 太田さんはここで言う'others cdr'をtagと呼んでいるように見えます。 > そういえば原案ではS->Yをtagと呼んでいたような気もするので誤解を > 招く命名だったかもしれません。 僕の認識とまったく同じです。確かに'tagの上位bitを占めているvalue'というとそうも 取れますね...。'tagの上のbitを占めている部分'という意味で使ったんですが、曖昧 でした。 > 直接的ではあっても直感的ではないように思います。私のコードでは型 > 毎のtag幅を下の層に隠蔽する事によってアクセサ定義レベルでの操作 > の概念を単純にする事を狙っていました。 > > 今r1857のコードを見直してみたら一部のマクロ名が不適切でそうなっ > てませんでしたが、本来の意図はこうです。tagがextendedかどうかは > 上層から隠蔽し、どの型をprimaryに割り当てるかを変更しても影響が > 及ばないようにしています。 ふむふむ。 > 私が想定してた使い方はこんな感じです。名前はいいかげんなんで改訂 > の必要がありますが。 > > 前のメールで「なんでこれを抽象化しないで複雑な操作するかな」と言っ > てたのはこの辺です。アクセサ定義のレベルで意識したいのは「value > フィールドに対して値をget/setする」という事だけで、その詳細の知 > 識、例えばその型のtagがprimaryかextendedか、GC bitに何をセットす > べきか等は隠蔽されるべきです。 > > これらのアクセサをどのように構成するかは今後の開発状況により変わっ > てくる可能性があります(実際に今議論して変わりつつあります)。しか > し書き換えがコード全体に及ぶと作業が繁雑になる上に間違いの元にな > るので、今後も変わらないと思われる安定した部分、すなわちtagの構 > 成情報をどんな要求にも応えられるライフサイクルの長いコードにすべ > く汎用的な形で下層に分離しました。不要に見える定義が含まれている > のはそのためです。 > > このような設計方針は、対象の全体像がまだ掴みきれてない状態におい > てボトムアップ式にコードの粒度を上げるのに向いています。狭い範囲 > を抽象化して小さな粒を作り、それを土台にしてもう一段階大きな粒を > 作るわけです。設計の誤りや方針変更が発生した場合も下層の成果物は > 再利用できる場合が多いので、一層一層をしっかり固めておく事が大事 > です。手抜きすると余計な手戻りが発生します。 確かにSymbolだけを見れば綺麗です。それは認めます、はい。しかしですよ、String や CFunc、Pointer、Int等はこの抽象化の範疇に収まりきらず、かなり複雑な操作になっ てしまいます。結局下の層の中身を見てしまいますよね？なので、例外を作ってしまうな らむしろ層を密に結合させて、結合物を一つの層として見れば良いのでは無いかと思っ てしまうのですが、どうなんでしょう？この話は compact に限らず、色々な場面で応用 可能だと思うので、YamaKenさんの経験上こうした方が良いとか有れば教えて頂きたい です。 一層一層をライフサイクルの長いコードにするという意識は非常に勉強になります。そこ まで考え込んでコード書いていませんでした、反省。 > 原案では以下のようになってたので、ユーザ向けのマクロの方を > VOID_POINTERとかにするつもりだったのかもしれません。もう忘れまし > たが。 > > pointer type (0 = void *, 1 = ScmFuncType) > > 将来的な事を言うと、Cのポインタに限定しないで型付きのScmObjを収 > められるようにしたいです。現在envとerrobjは単なるlistですが、こ > れに型情報を付加するとコードの簡略化と安全性向上が見込めます。 確かに、あのMUST_POPは気持ち悪いですしね。この拡張性は持たせたままにしておき ます。 ------------------------------------------------- Kazuki Ohta : mover****@hct***** -------------------------------------------------
