Ceremonyまでの解消した問題
驚くべきことに、overwrite: to (operation) が不要になる対策が実現してしまいました。しかも追加したプログラムの量はあまり多くありません。（それはよかったですね。卒論前の切羽詰まった時期に研究室の席で仕様をまとめていたことを思い出します）
記憶装置の改修を進めています。サンプルプログラムは動くのにゆみっくすみくすコンティニュエーションは動かないというバグに慌てました。データ構造の変更点は、content に phantom ではなく NULL が入ること、テーブルが逆順ソートでなくなった（単純な追加順になった）ことです。direction に NULL が入ることは許していません。それをしたいならテーブルから削除してください。（遠い未来にはテーブルがバランス木に置き換わるでしょう）
記憶装置も改修します。ハッシュテーブルを操作する手続きを定義して、その上に可変長アドレスに対する記憶装置を構築します。（この提案は実現しました）
静的環境の改造がだいぶ進んでいます。名前は名前テーブルから引くようになりました。スタックを使って数字の貸し借りをするようになりました。番号を 1 から始めるようにしたので、無駄に 1 ずらしているところを削ります。これをまだやっていません！（この提案は実現しました）
あとはプリミティブ演算を名前ではなくベクトルで引くようにします。懸案のローカル化ベクトルの参照数の問題もなんとかします。（この提案は実現しました）
gismo_offset 関数は patsch.h に書かれていますが実体は存在しないようです。（この問題は解消しました）
decode_name と decode_constant_name と decode_number がぜんぶ別のソースファイルで定義されているみたいです。それぞれ machine.cpp, load.cpp, construct.cpp。これはひどい。パステルステッチの歴史的経緯を雄弁に物語る。しかも identify と identify_vector と identify_special というものもあるみたいです。（この問題は解消しました）
ええっと、変な名前を使われないためには、おおもとの decode_name （たぶん）だけを公開してあとは隠す必要があります。そうでないと null:system という名前のベクトルを作られたりします。（この提案は実現しました）
もののついでに、equal operation プリミティブ演算を削ったら、ゆみっくすみくすコンティニュエーションがこれを使っていて微妙にあれでした。（気を付けましょう）
プリミティブ演算型の単独データを作ろうとしています。これはプリミティブ演算テーブルを struct storage の流用で作るためです。準備として、とりあえず require_reuse を削りました。（この提案は採用されませんでした）
基底ベクトルの番号について、データ構造を大幅に見直します。返却された番号をスタックで持つことにより高速化します。使用中の番号をインデックスとする配列を作り、番号管理の中心とします。番号は名前つき、ギズモ、ローカル化オフセットの3種類です。逆引きの名前テーブルは別に作ります。（この提案は実現しました）
番号管理テーブルのローカル化オフセットのエントリーは、使用数を保存しています。これはコンテクストホルダーが作成された時点では 1 で、コンティニュエーションが作られると増えます。コンテクストホルダーを削除すると 1 減ります。このとき使用数が 0 になったローカル化オフセットは削除予約キューに入ります。仮想マシンがステップを開始するとき、このキューが空でなければ削除を実行します。（この提案は実現しました）
現在 struct singular に入れられている size メンバーを活用します。さしあたってはベクトルを 0 終端ではなくサイズで管理するようにします。ベクトル演算を全面的に改修します。（この提案はおそらく採用されません）
- 最終更新:2008-11-16 00:44:12