解消した問題（Amenityまで）

set character 演算の仕様が汚いです。get character は、引数が不正なときには false を返すべきです。（この問題はおおむね解消しました）

get character は直接目的語でテキストを指定、引数 index で位置を指定します。直接目的語がテキストでなければエラーです。引数 index は省略されている（false でもよい）か、範囲内の整数でなければなりません。index を省略すると最初の文字を読みます。（この提案は実現しました）

set character は直接目的語で文字を指定、引数 text でテキストを指定、引数 index で位置を指定します。直接目的語が整数でなければエラーですが、UTF-8 文字列としての正しさは確認しません。引数 text は省略（false）かテキスト格でないといけません。引数 text を省略すると空文字列とみなします。（次の段落に続く）

引数 index は省略（false）か整数でないといけません。引数 index を省略すると文字を末尾に追加します。引数 index が整数だとテキストの既存の文字を上書きします。このときテキストの範囲外を指定するとエラーです。もしテキストの末尾の次（基底言語が C であれば終端文字がある）をインデックスとして指定しても末尾に文字を追加することはできません。それをするためには index を false にします。テキストの途中に終端文字を書き込むと、テキストはそこで切られ、残りは捨てられます。（この提案は実現しました）

水面下での変更として、変数と名前の統合を行います。変数は context, trans context, offset holder context の 3 種類になります。また、アドレス変換イメージをフローの外に出します。（この提案は実現しました。けっこう大変でした。indirect 構造体の parent の設定を途中で間違えました。）

うすうす感づいてはいたのですが、number_gismo と gismo_table が正しく初期化されていません。（この問題は解決しましたが、2008年5月3日版には間に合いませんでした）あと、Firefox のスペルチェック機能が gismo に文句を言ってくるけどいいのかな。（別に問題ないと思います）

represent_context にコンテクスト・ホルダーとして NULL を与えるとセグルトします。そもそもは環境フレームのたぐいを一番上までたどったときの仕様が場当たりなのがよくない。（コンテクストホルダーが NULL になるのは、ローカル化コンテクストにおいては正しい動作です。環境フレームが NULL になったときどうすべきかは検証されていません）

システム演算と非局所制御がうまく組み合わされていません。システム演算はコールフレームの verb ではなくインダイレクトフレームの image を読むようにします。（作業中です）

何もないところで break や escape を打ったときの仕様がはっきりしていません。break は何もせず次に進みます。escape も何もしません。exit は「プログラムの外」で実行することがありえないので、問題ありません。（この提案は実現しました）

set character 演算は文字列の末尾に追加するのをやめました。引数は直接目的語が文字コードの番号で必須。引数が直接目的語のみのときは1文字のテキストを作成。引数にさらに text と index を指定すると、テキストの指定した位置を上書きして返します。（この提案は実現しました。）

手続きは procedure write を残す方針のようです。引数が write である場合にはステップ実行になります。引数が anchor または object のときは非局所制御です。強さは overwrite より弱く write より強いです。非局所制御であれば引数 when で条件を付与できます。（この提案は採用されませんでした）

非局所制御の実装がたぶん終わりました。タブーリストを使って無限ループを巧みに回避します。動作が目に見えて遅くなりました。リリースはちょっと待ってください。（メモリリークの問題を解決するまではリリースしない方針のようです）

組み込み演算（system_operation, standard_operation, primitive_operation）は引数に述語と前置詞句を個別にとるようにしました。しかし、アドレス変換の結果を埋め込み演算に反映する仕組みはまだです。（この提案は実現しました）

現状ではevacuateはoverwriteより強いようですが、overwrite, evacuateの順で問題ないことがわかりました。中盤の連中、すなわちシステム演算、手続き、記憶装置の優先順位は検討中です。（この提案は実現しました）

break 文で手続きから抜けてしまったり、逆に手続きに入ったりするとたいへんなことになります。実行時かコンパイル時、できれば両方でエラーを出すべきです。（コンパイル時にはエラーを出します。さらに、手続きから抜ける break は escape に化けます。手続きに「入る」breakについては検討中です）

mulde 領域に引数を与えるのが反映されていませんでした。すぐに治せるので治しなさい。（治りましたが、コールフレームの削除忘れを発生させました）

situation 領域は廃止します。非局所制御の発動条件は前置詞句 when（用語についての議論を歓迎します）で指定します。（この提案は実現しました）

手続き格のデータは存在しないことにしてしまいました。現状ではヘッダファイルでデータ構造は定義されていますが、手続き格のデータを生成する方法がありません。mulde と procedure は手続きの開始アドレスを singular 型に詰め込まないで直接受け渡します。とばっちりで procedure-write は廃止されました。（この提案は実現しました）

break は直接目的語が false または省略のときループを抜けます。（この提案は実現しました。escape や exit との一貫性はありませんが、まあいいでしょう）

基底言語 C からのインターフェースは resume のみにします。引数は名前、静的環境、プログラムで戻り値は静的環境です。名前に NULL を与えると動的環境を新しく作って実行します。virtual_machine を resume 以外から呼ぶのは非推奨です。（この提案はおそらく採用されません）

退避 evacuate は overwrite によって上書きされる記憶素子を退避するという意味合いになります。実装としては、evacuate と overwrite は同じ強さで同じ構文を持つ双子の非局所制御です。ただし、evacuate によるアドレス変換の結果は overwrite のターゲットにならないという特徴があります。（この提案はだいたい採用されましたが、overwriteとevacuateは同格ではなく、overwriteが強いです）

非局所制御の引数を計算しているあいだは自分自身を無効にします。content-write や when 引数については無限ループを回避しますが、from-write では無限ループを起こすことができます。（この提案は実現しました）

現状ではターシャリーに一任されている（そして手抜き仕様に成り果てている）姓の補完についてのシステムが、言語マネージャ、コンパイラ、実行環境のいずれから使われるようになります。姓を明示した形で使用されたことのない固有名は姓 open を持つものとしたうえ、姓が明示されたときには同じ識別番号を持ちます。さらに別の姓が仕様されたときには、曖昧であるというエラーになります。（この提案は採用されませんでした。現状の、なんでも system にする機構は思った以上に良い案だったようです。ただし system という名前についての議論は受け付けます）

メモリリークは直ってしまいました！

小さなメモリリークはまだまだあるようですが、とりあえず影響が大きいものを潰しました。ものすごく高速かつ軽快に動きます。サンプルプログラムが。mtrace は超強力です。（まだ 1000 回くらいのメモリリークが残っています。メモリ使用率は 0.5% くらいです。）

将来的には、トランスコンテキスト、手続きの実体検出、アドレス集約の逆探知など地味な連中もそのうちなんとかします。（この提案は実現しました）

overwrite を使うと重くなるのはメモリリークのせいらしいです。CUIアプリケーション、しかもサンプルプログラムのくせにメモリを10%も使ってはいけません。（あまりにも影響の大きいメモリリークは直しましたが、小規模なものは放置されています）

procedure ブロックは引数にベクトルだけを取れるようにします。to, domain ロジックを流用するのはちょっと良くない。（この提案は実現しませんでした。underwrite 非局所制御族の to キャッシュを流用していますが、domain と from は使いません。いずれにせよ、手続き定義の引数に集合を置くことができてしまいます）

これで速くなります。

overwrite: to (operation)

（メモリリークがおとなしくしていれば、体感できるほどの変化にはなりません）

特殊コンテクストは self, offset, essential です。あと親のコンテクストを参照するものとして parent offset の系列があります。特殊なコンテクストホルダーとして mulde、メインルーチン、グローバル記憶領域があります。次の段落に続く。（この提案は実現しました）

実際に呼ばれた手続きは述語部が #self になります。mulde, メインルーチン、グローバル記憶領域は、いずれも「呼ばれる」ことがないので、#self は false になります。#offset は手続き、mulde、メインルーチンがそれぞれ独自の基底ベクトルを持ちます。グローバル記憶領域の #offset は零ベクトルです。メインルーチン、グローバル記憶領域の #essential はそれぞれ main routine, main storage という専用の有名ベクトルになります。手続きの #essential は procedure 非局所制御の引数です。mulde の #essential は親コンテクストホルダーの #essential にベクトル mulde を足したものです。手続きと mulde は引数を明示することで #offset と #self を上書きできますが、#essential は強制です。# parent offset の系列は参照される親コンテクストの性質によります。（この提案は実現しました）

evacuate の優先度は中盤連中よりも下になりました。underwrite よりは上です。退避先をシステム演算、手続き、実記憶で埋めてしまうと絶対に読み出せなくなります。（この提案は実現しました）

ターシャリーに前置記号 @, $ を追加します。ついでに # の扱いもなんとかします。（この提案は実現しましたが、ターシャリーには古い # 変数に由来するコードが残っています）

トランスコンテクストは、最後に完成したコールフレームの引数です。継承元コンテクストは、ローカル化継承によって継承元となっているローカル化ベクトルを保持しているコンテクストホルダーの変数です。#, $, @ はいずれも前置記号だと思うのでこれらを使います。（この提案は実現しました）

手続きについての特殊なコンテクストとして、「本質」「本来の」という意味合いの言葉を募集中です。現時点の候補は essencial。手続きを定義している procedure 領域の直接目的語をそのまま返します。なお、このコンテクストの値は「アドレス集約の逆探知」の最初の値とは別です。（この提案は実現しました）