2010/01/30

Common LispとScheme

Common Lispリハビリ中。

CLとSchemeを渡り歩く時にひっかかるのは、関数名や構文名が微妙に 違うことととかLisp-1 vs Lisp-2とかじゃなくて、 もっと漠然とした、しかし根本的な「文化」のようなものである気がする。

CLってわりと何でもLispの中で解決しちゃう傾向が強くて、 ビルドシステムもユニットテストもデバッガも全部Lispで、 REPLからAPIをキックすることで何でもできる。基本、REPLを離れる必要が無い。 一応オートメーションのためにMakefileはあるけど、 中では単にlisp本体を起動してビルドスクリプトを 読ませてるだけとかね。 OSから全てLispだった時代を引き継いでいる文化なので、 むしろLispの外に出ることの方が特例なのだろう。

大規模ソフトウェアだと、このLispで書かれたベースのシステムの上に そのプロジェクト特有のコンフィグファイルを読ませたり テスト時のサーバプロセス起動を自動化したり…といったレイヤがやっぱり Lispで書かれて載っかってる。

また、大きめのプロジェクトだとソースファイルがいろんなサブディレクトリに 分散してるけれど、一度asdfなどのビルドスクリプトをちゃんと作っちゃえば 後はソースの位置を意識する必要がほとんどない。関数定義を追っかけるのは Emacsから直接飛べるから。

Schemeの場合、といってもScheme界も一枚岩ではないのだけれど、 もともとの言語仕様が小さいのと、Unix族の上で発展した 処理系が多いためだろうか、言語機能の外の話、つまりビルドや各種テスト、 コンフィグレーション、配布パッケージ作成などは、 積極的に言語の外のツールを使おうという傾向があると思う。

すると、あるプロジェクトに参加してとりあえず全体の構成を把握したり ビルドやテストのプロセスを知ろうとした場合、Schemeのプロジェクトだと そのへんは言語よりもUnix一般の知識を使って見て行くことになる。 GNU以降のオープンソースな処理系だとだいたいそのへんは共通してたりするので 処理系毎の細かい違いに足をとられる前に全体を把握できる。外から中へ 見て行く感じだ。

全部Lispで完結するCL上のプロジェクトの場合、逆にとりあえず REPL起動してasdfでビルド/ロードして、aproposやタグジャンプを使って Lispの「中から」全体を把握してゆく方向になる。 ここで「外から中」を混ぜるとうまくいかない。ファイルシステム上で Makefileや*.asdを覗きながらビルドの依存関係を追っていくのは、 規模が大きいとかなり辛い。特にビルドが何段階にもなってたり、 途中コンフィグファイルが自動生成されたりしてると。 プロジェクト独自のレイヤがLisp上に載っかってる場合は、 とにかくREPLからそういうレイヤを突っつけるAPIを見つけ出して 慣れることが早道だ。

けれども私自身はUnixで育ったので、どうもファイルを基本に 考えちゃうところがあるんだなぁ。何がどのファイルにあるかの マップが頭の中に無いと迷う感じ。タグジャンプしまくってると 迷路を彷徨ってる気がしてくる。

まあ、ファイルの位置とソースの構成との紐つけが緩いのは 最近のIDEとかでもそうなんで、むしろファイル構成と ソース構成を対応させたいって意識の方がUnixべったりすぎるのかもしれない。

Tags: Programming, Lisp, Scheme