空飛んできた。

イアンさんが自家用飛行機に乗せてくれると言うので、ちょっと空飛んできました。最高に快適でした。

この近辺には小さな空港が沢山あって、その一つサンタモニカ空港にイアンさんの飛行機クラブがあります。そこでプロペラ機を借りて遊べるわけです。

飛行機は遠くから見ると大きかったけど、近くで見ると人が乗り込む部分は私の車より狭くて、こんなに小さくて大丈夫か？！と心配になります。前の席にはハンドルとペダルが二組あって連動しています。万が一の時は助手席の人が運転出来るようになっているのです。席に乗り込むとイアンさんが、万が一自分が気を失ったら、ここのレバーを COM2 に合わせて、ハンドルのこのボタンを押しながら、「メーデー、メーデー、パイロット、イズ、アンコンシャス」と言うように、と私に言いました。えー！！そんな事態が起こったらどうしようも無いじゃないか！

非常事態の際はアムロのように突然見知らぬ機械を操作しなくてはならないのだと使命感に燃えて、イアンさんの動作の動作を凝視して頭の中でシミュレーションを繰り返しながら離陸に備えます。

離陸はあっけなくて、ものの数十メートルも行かないうちにフワっと浮き上がってしまいました。そして優雅に遊覧飛行です。ものすごいスリルを期待していたのですが、あまりにもイアンさんの技術が上手すぎて、普通に車でドライブしている感じです。ただ音がうるさいので会話はマイクを通じて行います。

時折ヘッドホンからは他の飛行機と管制官が会話をしているやり取りが聞こえます。飛行中他にもユナイテッドの旅客機や、同じような自家用機を何機か見かけました。ロサンゼルスはだだっ広くて、遠くまでプール付きの家々が広がっています。写真は良く見えないと思いますが、グリフィス天文台とハリウッドサインも写ってます。

ふと、機体の音が静まり、イアンさんが真面目な顔をし始めました。いよいよヤバイのか！と思ったら目前に滑走路でした。最後はプロペラの出力を下げてゆっくり着陸です。着陸も、地面に付いたかと思えばちょっと行って終わりで、短くてびっくりしました。

旅客機には何度も乗ってるけど、自家用機の体験は全然違う物でした、自分が普段生活している空の上に行く事が出来るというのはかなり目からウロコです。飛行中ずっと宮崎アニメな気分でした。

テキストエディタの数学的表現を探す

昨日眠れなくてずっと布団の中で考えていたメモです。意味と実装という言葉がよくプログラミングの中で使われます。意味は二つのオブジェクトの間の関係を表していて、例えばテキストエディタで言うとテキストデータと実際に表示されるビットマップとの間にはある種の関係の事で、例えば横 80 桁固定のテキストエディタだとすると、

• 文字列が必ず横 80 文字で折り返す、とか、
• A のフォントはこれこれこういう形である。

とか、宣言的に書く事が出来ます。また、実装とは、その関係をコンピュータ上で実行するために必要なプログラムの事を言います。例えばキーボードから A が押された時に、

• バッファに A を挿入する。
• 入力位置のテキストを書き換える。
• もしも入力位置のテキストが80文字を越えていたらそこから下全部書き換える。

などと、操作的に書く事が出来ます。問題は、意味から実装を機械的に作る事は出来ないのだろうか？出来ないとしたら、どこまでなら出来るのだろうか？という事です。以前微積分を使ってのメタファを書きました。 http://d.hatena.ne.jp/propella/20080405/p1 今、圏論を使うと良いのではと思って色々調べていますが、難しすぎて歯が立ちません。でもとりあえず思いつきだけ書きます。

旧テキストデータ -> テキストデータ差分 -> 新テキストデータ
  |                   |                   |
  | 表示関係           | 本当の実装         | 表示関係
  V                   V                   V
旧表示データ     -> 表示データ差分     -> 新表示データ

テキストデータとは、文章の内部表現(例えば文字列)、表示データは、表示に使う情報(例えば 80 桁で折り返した後の行頭インデックス配列)という事にします。上記の宣言的定義をそのまま実装すると、テキストから表示データへの関数が出来上がりますが、このようなエディタは役に立ちません。なぜなら、入力によって変更される文字は全体の一部なのにも関わらず、表示データ全体を再計算し直すのはコストが高すぎて実用的では無いからです。という事で、普通は差分だけ処理する実装を行います。が、ここで現実は関数のように綺麗にいかないよなーとボヤくのでは無く、差分プロセスの処理もちゃんと形式化しようというのが趣旨です。

具体的には、テキストデータを直接表示する代わりに、テキストデータの差分から、表示データの差分を得る関数を定義します。そして、表示データと表示データ差分を使って、更新後の新表示データを作ろうという物です。普通の言葉で言うと、ダメージ領域とオブザーバパターンで更新を拾って必要な所だけ描くという事です。これを上の図で言うと、旧テキストデータから新表示データを得る為にいくつかの経路があって、最も低コストの経路を選ぶと言うのがプログラミングという事になります。この図式を説明するのに、数学の言葉を使いたいのです。

なぜなら、上の図くらいなら簡単で良いですが、オブジェクト指向プログラミングの中にはこのような図式が縦横無尽に入り組んでいて、しかもその場限りの適当な名前(パターン言語)が付けられて全然体系化されていないからです。これって、圏論(でも何でもいいけど)で言うとただの○○だよね！と誰かが言ってくれる事を願っているのです。

例えば、テキストデータから表示データを求める操作を圏として、テキスト差分から表示差分を求める操作も圏で、この二つの関係は函手だよねー(分からないで適当に書いている)という事になると、色々メソッド名とかを考える手間が減るし、みんながそういう常識を持ってプログラムを読むようになると誤解が減るという物です。

疲れたので勉強しなおしてからまた書きます。