IanのTCP/IPスタック

http://practical-scheme.net/wiliki/wiliki.cgi?Shiro
で呼ばれました(「編集」のボタンが押せるのですが、いきなり編集してもよかったのでしょうか?)。

もひとつ、これも上に挙げた文法のカスタマイズにつながるんだけれど、問題のドメインがはっきりしている場合、それ用のDSLで書いてある方が検証しやすい。たとえばAlan KayのとこでIan Piumartaらがやってるプロジェクトでは、RFCに書かれてるTCPの仕様をDSLとして解釈してコンパイルすると実際に動作するTCPプロトコルスタックになる、というのを書いたそうだが(大島さん、間違ってたらツッコミお願い)、ここまでやって問題が出たらそれは仕様のバグってことになるわけだ。ここまでやらずとも、DSLを使うというのは、問題領域で使われる概念に良く対応する言葉を組み合わせてプログラムするということだら、プログラマの意図がより明確であり、その意図に照らした検証がしやすいと言えるだろう。

あともひとつ。これもIanの受け売りに近いんだけど、こうやってメタプログラミングを極めて行くと複雑なシステムがえらくコンパクトに書けるようになる可能性がある。実際、彼らはOS・言語処理系からアプリに至るまでの全てを20000行で書くというプロジェクトをやっていて、ネイティブコンパイラが1000行ちょい、とかは既に実現されてる。 で、1000万行のシステムと2万行のシステムなら後者の方が検証ははるかに楽だろう。1000万行のシステムの99.8%が機械的に除去可能な冗長性でない限り。 (そうそう、Ianのやつは上の「C的なレイヤ」の話の反例にもなってると思う。)

Ianのやつの話の一部は

http://piumarta.com/svn2/idst/trunk/function/examples/tcp/net-ip.k

みたいなやつで、確かに仕様書から切り出してきたものを元にパケットのフィールドのアクセサを生成したりするので、その部分は確かに仕様からの乖離の仕様のないものになっています。ただ、彼のTCP/IPの例で言うと、

http://piumarta.com/svn2/idst/trunk/function/examples/tcp/tcp2.k
の一番下にある文法で入力ストリームのパケットをparsingすることが仕様にある状態遷移になっているのだ、というところは飛躍があるので、そこは「短いがために人間による検証ができる」というところが味噌になっていますね。

コンピュータが扱う複雑性はやっぱり普通の数学が扱うことになっている規模とは相当に違うので、新しい数学としての発明がさらになされていく必要があるというのは確かですね。