著者Paul Graham氏のサイト上のページ(原書PDF, コード, 正誤など)

訳者 野田開氏による翻訳草稿(TeX, PDF, HTML)

出版社のカタログ

(do*
((x 1 (1+ x))

(result (list x) (push x result)))

((= x 10) (nreverse result))))
しかしこの方法は格好悪いし非効率だ2. 代わ
りに新しいmap 系関数map1-n(p. 55参照)を定義し,それを次のように呼び出
せばいい:
(map1-n fn 10)
関数を定義するのは比較的真っ当な方法だ.マクロは
新しいオペレータのさらに一般的な(しかしあまり理解されていない)定義
方法を提供する.マクロはプログラムを書くプログラムだ.この文には非常に深
い意味が込められている.そしてその探求はこの本の主目的の一つなのだ.
マク
ロを注意して使えば驚異的に明解でエレガントなプログラムができる.もちろ
ん,これらの宝石のようなプログラムがただで得られる訳ではない.最後にはマ
クロは世界で一番自然なものに思えるだろうが,最初は理解が難しい.これはマ
クロが関数よりも一般的で,書くときに注意すべきことが多いせいもある.しか
しマクロの理解が難しい大きな理由は,それが全く異質(foreign) なものだから
だ.Lisp のマクロのようなものを持つ言語は他にない.だからマクロを学ぶに
は,他のプログラミング言語から気づかずに学んだ先入観を振り捨てることを
要求されるかもしれない.そのなかの主要なものは,死後硬直に悩まされるプロ
グラムという概念だ.なぜデータ構造が流動的で変更可能であるべきなのに,プ
ログラムがそうであってはいけないのだろうか? Lisp ではプログラムがデータ
であるのだが,この事実の持つ意味をモノにするにはしばらく時間がかかる.
2 これは新しいCommon Lisp のシリーズマクロを使ってもっとエレガントに書くこ
ともできる.しかしこれらのマクロ自体がLisp の拡張なので,結局は同じこと
だ.
マクロに慣れるのにしばらく時間がかかっても,それは努力に見合うこと
だ.繰り返しのようなありふれた用途でも,マクロはプログラムを抜群に小型で
きれいなものに変える.ここで,あるプログラムがコード本体をx についてa か
らb まで繰り返さなければならないとしよう.Lisp 組み込みのdo はもっと
一般的な目的のためのものだ.それを単純な繰り返しに使うと一番読みやすい
コードにはならない:
(do ((x a (+ 1 x)))

((> x b))
(print x))
こ
れを,こう書けるとしたらどうだろうか:
(for (x a b)
(print x))
マクロがこ
れを可能にする.6 行のコードで(p. 159 参照)for
文をこのプログラミング
言語に追加できる.そしてそれは初めからあった構文のように機能する.後の章
で見るように,for
の実装はマクロでできることの手始めでしかない.
Lisp の
拡張で一度に使えるのは関数やマクロ1 個ずつに限られる訳ではない.必要とあ
ればあるプログラミング言語全体をLisp の上に構築し,それを使ってプログラ
ミングすることもできる.Lisp
はコンパイラやインタプリタを書くのに最適の
プログラミング言語だが,新しいプログラミング言語を定義する別の方法を提供
する.そのほうがしばしばエレガントだし,労力が少なく済むのは確かだ:それ
はLisp
を修正して新しいプログラミング言語を定義する方法だ.そうすれば
Lisp
の機能のうち新しいプログラミング言語でも変更せずに使える部分(例え
ば算術演算やI/O)はそのまま利用でき,異なっている部分(例えば制御構造)
だけ実装すればいい.このように実装されたプログラミング言語を埋め込み言語
と呼ぶ.
埋め込み言語はボトムアッププログラミングの自然な帰結だ.Common
Lisp には既にいくつか例がある.一番有名なCLOS については後の章で議論す
る.しかし自分だけの埋め込み言語を定義することもできる.自分のプログラム
に適した埋め込み言語を作ることができ,それをLisp とかけ離れたものにする
ことさえ可能だ.
1.5 なぜ(またはいつ)Lisp か
これらの新たな可能性は
魔法の要素たった1 個から生まれる訳ではない.この点を見れば,Lisp はアー
チのようなものだ.楔形の石(迫石?2)のうち,どれがアーチを支えているの
か? これは質問そのものが誤っている:どの石もアーチを支えているのだ.
アーチと同様,Lisp は組み合わさった機能の集合体だ.それらのいくつかをこ
こで挙げることができる動的メモリ割り当てとガーベジコレクション,実行時
型指定,オブジェクトとしての関数,リストを生成する組み込みパーサ,リスト
として表現されたプログラムを受け付けるコンパイラ,インタラクティブな環境
等々しかしどの一つをとってもLisp の持つ力の理由にはならない.Lisp プログ
ラミングをLisp プログラミングたらしめているのは,そのコンビネーション
だ.
過去20 年でプログラミングの方法は変化した.インタラクティブな
環境,動的リンク,オブジェクト指向プログラミングまでこれらの変化の多く
は,Lisp の柔軟性を幾分かでも他のプログラミング言語に与えようとする細切
れの試みだった.アーチの喩えは,それらがどれほど成功を収めたかを示唆して
いる.
Lisp とFortran が現存するプログラミング言語のうち最も古いものだと
いうことは,よく知られている.おそらくもっと意味のある事実は,それらはプ
ログラミング言語のデザインの思想のうち対極にあるものを代表しているという
ことだ.Fortranはアセンブリ言語からの進歩として開発された.Lisp はアルゴ
リズムを表現するプログラミング言語として開発された.そういった異なる意
図は,大きく異なるプログラミング言語を生んだ.Fortran はコンパイラ開発者
の人生を楽にしてくれる.Lispはプログラマの人生を楽にしてくれる.そ
れ以来,大抵のプログラミング言語は2 つの極の間のどこかに位置するものだっ
た.そしてFortran とLisp は真ん中に向かって歩み寄ってきた.Fortran は今
ではずいぶんAlgol に似てきたし,Lisp は若かりし頃の無駄な習慣をいくつ
か諦めた.
最初のFortran とLisp は一種の戦場のようなものを定義した.片方
では鬨の声は「効率~!(それに実装が大変すぎるだろうし)」で,もう片方で
は鬨の声は「抽象化~!(これは商用ソフトじゃないし)」だ.古代ギリシャ
の戦争の結果を神々が高みから決めたように,この戦の結果はハードウェアに
よって決められるようになっている.年を追うごとに情勢はLisp
側に有利に
なってきているようだ.今ではLisp に対する議論は,1970
年代初頭にアセンブ
リ言語プログラマたちが高水準プログラミング言語に対して仕掛けた議論に非常
に似てきた.今や問いはなぜLisp か? ではなくいつLisp か? になっている.
*2 訳注:voussoir: アーチや丸天井に使われる楔形の石材.