_ 継続、を説明できるかどうか試してみる

zundaさんのメッセージ を見て、 継続って案外理解しにくいものなのかな？と感じたので、 自分なりに説明してみます。 実際に使ってみたら、あっさり理解できそうな気もしますが...

私自身の考え方は全般的にマシン寄りです。 プログラムがマシン上でどのように実行されるのか、 モデルが頭の中にあって、 それをベースに捉えます。 こういう考え方で継続を説明した例としては、 shiroさんのなんでも継続 がすでにありますが、 私なりの言葉で書いてみます。

例えば、古典的なチューリングマシンのようなものを考えます。

aとbを足して、cに入れる → cとdを掛けて、eに入れる

昔フローチャートで仕様を作って、 それでプログラムを書くなんてことが行われていたそうですが、 プログラムは上記のようにフローとして捉えることができます。 そして、そのフローは命令列によって記述されます。 「aとbを足して、cに入れる」は命令の一つです。

ここで、実際に命令を実行して何が起きるかは、 状態に依存します。 最初の命令で、「c」に何が入るかは、「a」と「b」に依存します。 こういう「やりたい命令」と「依存している状態」をセットにして考えてやります。 これを俗にコンテキストと呼ぶことがあります。 マルチタスクとかでよくあるアレです。

そして、このコンテキストの別称が継続です。 というと、コンピュータ・サイエンスの人には乱暴すぎて怒られるかもしれませんが、 大体そんなところです。

じゃあどうして継続などと呼ぶかと言うと、 単なる考え方の違いです（ますます乱暴）。 要するに、続けられるコンテキストだから、継続。

もうちょっと形式的な考え方をすると、 プログラムから見えるデータ集合 D、 プログラムを記述する命令列 I_j に対して、 D, I_j+1 = I_j(D) を順次適用するのがプログラム。 とか言うと、副作用のない純粋関数型思考の人にはいやーんでしょうけど。 でもマシンレベルでも何でも副作用ありまくりなのが現在のコンピュータなので、 入力と出力を完全に分けることはできないのであります。

そこで、何が嬉しいかを考えるのは置いといて、 ある I_j を（順次実行でない方法で）実行するにはどうすればいいかを考えます。 答えは明らかで、 j とその時点でのデータ集合 D_j を保存することです。 もし継続したいなら、何をやっている（どの命令を実行しようとしている）のかと、 どんなデータの状態なのかを保存しておいて、 それを復旧すればいいのです。

しかし、全部のデータを保存することは現実的ではありません。 例えば、インターネットからHTTPでファイルを取得して、 それを解析するとしますと、 厳密にはそのインターネット上のファイルや、 それどころか、インターネットの接続状態まで保存・復旧できないといけません。 でも、こんなことは到底不可能です。

そのため、現実には D_j の部分集合 D^'_j を保存・復旧することになります。 いずれにせよ、プログラム的にも全部が D_j になっちゃうより、 部分的に D_j になるだけの方が都合が良いことが多いのです。 例えば、大域変数はそのまんまの方が、別処理を割り当てられたりしますし、 保存するコンテキストが順次変わっていく方が嬉しいこともあります。

その部分集合の作り方には、 言語的・処理系的に決まってしまう部分とそうでない部分があります。 例えば、Rubyだとローカル変数は部分集合に含まれますが、 インスタンス変数は含まれません。 使いたい人のための継続入門 に書かれているように、 評価の優先順位に依存したりします。

ここで、言語的・処理系的には部分集合に含まれるものの、 そうなって欲しくない場合のために、 プログラマが部分集合の取り方をコントロールできるのが部分継続です。 Schemeならcall/pcとかで実現します。 Rubyでは出来ないと思います（が、工夫次第で似たことは出来ます）。

で、実際的に部分集合 D^'_j をどうやって保存しているのかと言うと、 スタックとかPC（プログラム・カウンタ）とかを保存することになります。 この辺はもう処理系にばりばり依存する話になってしまうんで、 適当なマニュアルやソースコードを見てください。

まとめ。継続というのは、つまりワープなんです。 スティール・ボール・ランのように、 時間を巻き戻しても、認識しているやつは巻き戻す前のことを覚えているでしょ？ ああいう感じに、全部が戻るわけじゃないけど、 大体戻るんです。 と、全然まとめにならないで発散してしまうのであった...

_ 原稿書き

うむ、現実逃避はこの辺でやめよう。 原稿書かねば。

_ 薄い肉

半分ぐらい書いた。でも全然乗らない。 諦めて、また現実逃避行してる。

フランスでは薄切り肉がない。 と言われてきた。 日本人は薄切り肉が欲しい。 でも、ない。

そこで古来より日本人は肉を半冷凍して切断するなど、 偉大な苦行を成し遂げてきたのである。

しかし苦労は報われた。 遂に薄切り肉登場！ カルパッチョ用の肉がCarrefourに出現したのだ！ もはや、むむ、これぐらいなら薄いかな？などと呟きながら夜な夜な包丁を振るう必要はないのだ！

冗談はともかく、これで焼肉風をやってみたが、 やっぱり薄い肉は違うねえ。 焼肉「風」なのは、あいかわらずうちの調理台は電気が通じないのか、 壊れたまんまなんで、電子レンジで頑張るしかないからなのだ。 焼くのは大変だが、それっぽいものは作れる。 電子レンジによる調理に関する限り、 私は一流かもしれん。

_ 日本を代表するプログラマ

全然関係ないが、 以前何とかの調査とかで、日本を代表するプログラマを三人挙げよ、 と問われたことがある。 偉い人はいっぱいいるのに、私のような虫けらが優劣を付けるなど、おこがましいことだと、 一度は返答を拒否したのだが、どうしてもと言われて、嫌々選んだことがある。

その時挙げたのは、多分、gniibeさん、ukaiさん、itojunさんだったように思う。 このうち私と面識がないのはitojunさんだけだが、 これらの人々が偉いのは異論のないところだろう。 無難だと思って選んだってところもあったと思う。

しかし日本を代表するってのが難しい。 二つ考え方があって、日本の中で有名、偉業を成し遂げたと認識されているというのもあるだろうし、 世界的に見て、おお、こいつは偉い奴だ、と思ってもらえる日本人というのもあるだろう。 私の基準は後者だった。 私自身、すでに日本にはいない身だったし、 日本でしか認識されない人を「代表する」というのにはちと抵抗があった。

もちろん、これらの方々以外にも十分「代表する」に値する人はたくさんいるだろう。 だから選びたくなかったのだけど、 私もそこまで冷酷な人間ではないので、 どうしてもと言われると断れないのであった。

ところで、唐突ではあるが、代表するかどうかは知らないが、 世界で最も偉いプログラマはRoland McGrathである。 他の人が何と言おうと、私はそう思っているのである。

私が誰かを本気で尊敬するには、 いっしょに何かやったことがないと無理なのである。 いくら噂ですごいと言われていても、実際にやっている姿を見ていない人物は判断しがたいのである。 rolandとは Hurd でいっしょにごにょごにょやっていた時期がある。

彼は、メディア的にはうけない人物だろうけれど、 これまでやってきたことは相当なもんである。 GNU libcの初期開発者の三人のうちの一人である。 Autoconfの主要開発者だったこともある。 GNU Makeの作者であり、 Hurdの作者の一人であり、 GNU Machの開発者でもあった。 他にもたくさんあるが、概して言えるのは、 重要なプロジェクトで重要な役割を演じてきた割に、 日陰の存在で在り続けてきたことかもしれない。 だから、知る人ぞ知る功労者なのである。

正直に言うと、人間的にはそんなに好きでないとこもある。 にもかかわらず、私が彼を尊敬するのは、 彼がプログラマとしての私の理想像に限りなく近いからなのだろう。

偉大なプログラマは美しく、無駄がなく、拡張性が高く、見通しの良いコードを書く。 偉大なプログラマは品質を落とさずに素早くコードを生み出す。 偉大なプログラマは単純でないプログラムの設計を正しく行う。 彼はそのすべてを満たしている。

私がまだとても追い付けていない領域である。 品質と両立させて開発速度を速めるのはとても難しい。 片方だけなら出来るけど、 両方は無理だ。

何だかrolandの誉め殺しみたいになってきたが、 全然違うタイプで尊敬する人物も他にたくさんいる。 例えば、rmsはすごいんだろうと思う。 あの年齢で今でもハックしているだけでもすごいし、 gccやemacsを書いたそうなので、 すごいに違いない。 しかし私は彼といっしょにプログラムを書いたことがないので、 本当にどれぐらいすごいのかはよく分からんのである。 プログラミングじゃない部分ではとても尊敬しているのだけど、 知らない部分は知らないとしか言えない。