関し「関数的(functional)」であることが条件になる。与えられれば、常に同じ「出力」をしなければならない。エミュレータを書く最初なので、拡張性は念頭に置きつつも、できるだけシンプルに書くことをこころがけた。仕様をすべて書き出してしまい。仕様を一つずつ実行するという形をとっている。プログラムにはループがありうる。して与えることにしている。プログラムの「メイン」部分はだいたい次のようになっている。それがどう機能するかを見るために、一つずつ多めにとってある。仕様をすべて表示する。仕様にもとづいてすべての場合について実行を行っている。仕様だけをすべて表示することになる。特徴により、実行順序がばらばらでみにくいかもしれない。仕様を満たしようがないと判断された部分を示している。実行すると、最後のほうが次のような表示になった。いうことで、もう少し枝刈りを改良する余地がありそうだ。関しては、上の例のところで挙げたものと一致している。(λ計算)を少し意識している。どれがどれを待つというのが重要になってるのに、私のエミュレーションでは、プロセスにとって大事な入力待ちの状態さえまったく出て来ない。機能する...といったように議論を持っていっていくことができるのではないかとか夢想している。今後いつか、そういった部分を理論的に詰めてみたい。仕様の木を伸ばしていくということも不可能ではなさそうだ。いらない実装もしてみたい。プログラムで(私にとって)複雑な排他制御を行おうとしたとき、本当にそれで意図通り動くかチェックしたいが、どうしたらそういうチェックができるのだろう?...と考えたことにある。いった「実用的」なプログラムに関してエミュレートできるようになるまでは時間がかかるだろうから、そこを目標とはしないが、それに向けた拡張は行っていきたい。後にそこにアクセスしても排他的なアクセスにすることはできる...といった機構を導入したい。ここでチェックすべきは、本当にアクセスが排他的になっているかということで、プロセスに与えられた「accessor」が同じ場合か違う場合というのを総当たりで挙動を確かめれば十分という話になろう。厳密な検証の文脈では、実行のオーバーヘッドはどこにでも起きうると考えるべきだからである。何をやっていることになるのだろう?それは、おそらく、エラーに関係する。今回の理屈を延ばしたところにおいて、エラーとはすなわち確率的な事象とせざるを得ない。いうことになるのではないか。使うということであるが、これは、ブロックという「エラー」の確率を減らす操作と考えることができよう。上の「今後の課題」をある程度やって、再びブログ記事にするときなどに折を見ながら、落ち着いて調べるといった手順になるかと思う。自分の記事のみ挙げておく。encyclopedia》。本稿とはまったく別(?)のアプローチ。ラムダ計算については適当にググるなりしてください。《Statuses_Editor_Proxy.CGI》。実装のオブジェクト指向の使い方は私の独特な書き方。この記事に「デバッガの代わりに理論的な極限状況を再現できるものとしてのエミュレータって感じかな。定理証明システムってことになるのかもしれませんが。