ここで、こうした全能デバッガがあるとして、必要とされるデータ構造について考えてみよう。なぜ考えるかというと、実は今やってる Croquet のための Devid Reed の論文の草稿(同じような事が書いてある)を読んでもイマイチ納得がいかなくて、こういう場合はまず自分でも同じ問題を考えてみるのが得策だと思うからだ。必要な物は、すべてのオブジェクトの時間を遡れる世界だ。
まず、ここでクラスを二種類に分けて考える。不変オブジェクトと、可変オブジェクト。不変、すなわち immutable な物とは、数や文字、シンボルなど、時間が変わっても決して値を変えない物が含まれる。これに関しては時間の影響を受けないので今までと同じで良い。問題は可変オブジェクトだ。注意すべきことは、クラス自体も可変オブジェクトに含まれる事だ。クラス定義は常に変わり得る。こういう物は、過去一つ前の状態を覚えるポインタが一つ必要だ。例えばこれをpast と呼ぶ。また、past の状態から現在の状態に遷移するにあたって原因となったコンテキスト、要するにメッセージ名と引数の組、そして送ったオブジェクトの情報 factor も必要だ。
- 不変オブジェクト : 状態を持たない。
- 可変オブジェクト : past と factor を持つ。
- factor : 送ったオブジェクト、メッセージ、引数の組
ここでのポイントは、オブジェクトは過去の状態を知っているが、未来の状態は知る必要が無いという事。えー。いわゆる一対多対応ですな。もちろん undo/redo を実装するために最適化の余地はあるが、今は理屈の話だけ押さえる。また、factor に含まれる他のオブジェクトへの参照は、あくまでもある時点でのオブジェクトの値になるため、例えばデバッガを触ってる間に他のプロセスが変数の値を触ってしまい、デバッグにならないなんて状況は起こらない。
factor はコンテキストに必要な状態をすべて持つので、逆に言うとコンテキストスタックのような物は無い。スタックではなく、状態樹がその代わりになる。状態樹のそれぞれの枝に当たる factor 自体は不変オブジェクトである。なぜなら、メッセージは不変だし、送信、受信オブジェクトとも、「オブジェクトのある時点の値」なので、不変だから。と言う事は再利用できる。過去に全く同じシチュエーションが起こった場合、その枝にジャンプ出来る。オブジェクトは過去を知るが、未来を知らないので矛盾は起こらない。また、すべての操作は関数的であると言える。状態は増殖はするけど現行のオブジェクト指向言語と同じ意味で更新される事は無い(過去を書き換える事は出来ない)。
うーん。単純すぎる気はするが、大丈夫なのかな。まだ実時間との同期は考えていない。実時間との同期は(Croquet の思想とは反して)、もっと上位のレベルでやるべきだというのが個人的意見。
ここから先は妄想の話。既に作られた状態樹を検索して、「似た状況」を扱う解析が出来る。もちろん、似た状況を検索したところで似た結果を得られるかどうかは定かではない。しかしある程度の予想を立てる事には使える。抽象的に書いているが、要するに歴史に学ぶ事、もしくは未来を占う事というのがコンピュータの基本機能の一つとして認識される。超巨大並列コンピュータカンパニーである未来 google 社の仕事は、web の探索ではなく、超高速に解析された未来予想になる。
