\documentclass[final]{onlisp_j} %{{{3
% vi:set et lisp tw=0 ft=tex fdm=marker isk+=-,*,\::
% $Id: onlisp_j.tex,v 1.12 2004/11/26 16:51:02 nodakai Exp $
\usepackage{fancybox}
\usepackage{times}
\usepackage[scaled]{helvet}
\renewcommand{\ttdefault}{cmtt}

\usepackage[dvipdfm]{color}
\usepackage[dvipdfm,bookmarks=true,bookmarksnumbered=true,bookmarkstype=toc]{hyperref}
\AtBeginDvi{\special{pdf:tounicode EUC-UCS2}}

\makeatletter % why must these be here?  I don't know...
{\catcode`\ =\active%
\gdef\@vobeyspaces{\catcode`\ \active\let \@xobeysp}}
\begingroup \catcode `|=0 \catcode `[= 1
\catcode`]=2 \catcode `\{=12 \catcode `\}=12
\catcode`\\=12 |gdef|@xverbatim#1\end{verbatim}[#1|end[verbatim]|vspace[-7pt]]
|gdef|@sxverbatim#1\end{verbatim*}[#1|end[verbatim*]|vspace[-7pt]]
|endgroup
\def\@verbatim{\trivlist \item\vspace{-4pt}\relax
  \if@minipage\else\vskip\parskip\fi
  \leftskip\@totalleftmargin\rightskip\z@skip
  \parindent\z@\parfillskip\@flushglue\parskip\z@skip
  \par
  \@tempswafalse
  \def\par{\narrowbaselines%
    \if@tempswa
      \leavevmode \null \@@par\penalty\interlinepenalty
    \else
      \@tempswatrue
      \ifhmode\@@par\penalty\interlinepenalty\fi
    \fi}%
  \let\do\@makeother \dospecials
  \obeylines \verbatim@font \@noligs
  \hyphenchar\font\m@ne
  \everypar \expandafter{\the\everypar \unpenalty}%
\def\verbatim{\@verbatim \frenchspacing\@vobeyspaces \@xverbatim}
\def\endverbatim{\if@newlist \leavevmode\fi\endtrivlist}
\def\verbatim@font{\normalfont\ttfamily}
\@namedef{verbatim*}{\@verbatim\@sxverbatim}
\expandafter\let\csname endverbatim*\endcsname =\endverbatim
}

\def\BVerbatim{%
  \catcode`\^^M=13\narrowbaselines\relax
  \@ifnextchar[{\@BVerbatim}{\@BVerbatim[]}}
\makeatother
\newcommand{\CLtL}[1]{\textsf{CLtL#1}}

% }}}3
\begin{document}    %{{{1
\title{\Huge\textbf{On Lisp}}\author{\\[2em]\Large{Paul Graham}}\date{}\maketitle
~\vfil\vfil\centerline{\large To my family, and to Jackie.}
\vfil\vfil\centerline{\large $\lambda\ldots$}\vfil\vfil\vfil~\newpage
\setcounter{section}{-1}
%}}}

\section{前書き}    %{{{
この本はLispプログラマとして成長したいと思っている全ての人に向けて書かれた．
読者が既にLispに親しんでいることを前提としたが，
長いプログラミング経験が必ずしも要る訳ではない．
始めの数章はかなりの量の復習を含んでいる．
これらの章はきっと熟練Lispプログラマにも面白く思ってもらえるだろう．
そこでは見慣れた話題に新しい光を当ててみたからだ．

あるプログラミング言語のエッセンスを一文で伝えるのは難しいが，
John Foderaroの言葉はかなりそれに近い：
\begin{center}
Lispはプログラム可能なプログラミング言語である\note{lispis}．
\end{center}
Lispはそれだけのものではないが，Lispを自分の意図に従わせることのできる能力は
Lispエキスパートと初心者との違いの大部分を占める．
熟練Lispプログラマは，プログラミング言語に従ってプログラムを書くのと同じように
自分の書くプログラムに向けてプログラミング言語を構築していく．
この本では，Lispが元々適しているボトムアップ・スタイルでのプログラミング方法を教える．
\subsection{ボトムアップ・デザイン} %{{{
ボトムアップ・デザインは，
ソフトウェアがどんどん複雑化していく中で一層重要になってきている．
現代のプログラムは，とてつもなく複雑だったり，
ときには解釈が定まらないような仕様を満たさなければならない．
そのような状況では伝統的なトップダウン方式が破綻してしまうことがある．
そこで，現在のほとんどのコンピュータ科学講座で教えられているのとは
大変異なったプログラミング手法が発達した：
ボトムアップ・スタイルだ．
そこではプログラムは一連の層として記述され，
それぞれの層がその1段上に対して一種のプログラミング言語として機能する．
そうして書かれたプログラムの例はX~Windowsと\TeX だ．

この本のテーマは二つある．
Lispがボトムアップ・スタイルで書かれるプログラムに対して
自然なプログラミング言語であるということと，
ボトムアップ・スタイルがLispプログラムを書くのに自然な方法であるということだ．
だから\emph{On Lisp}は2種類の読者にとって興味深いものになるだろう．
拡張可能なプログラムを書くことに興味のある人には，
この本は適切なプログラミング言語があれば何ができるのかを示す．
Lispプログラマには，この本はLispを最大限に活用するための実用的な説明を提供する．

この本のタイトルはLispでのボトムアップ・プログラミングの重要性を
強調するつもりで付けられた．
プログラムをただLispで書くだけでなく，
独自の言語を\emph{Lispを基に(on Lisp)}書くことが可能であり，
プログラムはその言語で書くことができる．

どのプログラミング言語でもボトムアップでプログラムを書くことはできるが，
このスタイルのプログラミングにはLispは最も自然な器だ．
Lispでは，ボトムアップ・デザインは異常に大規模だったり複雑なプログラム専用の，
特別なテクニックではない．
しっかりしたプログラムはみな，部分的にはこのスタイルで書かれることになるだろう．
Lispは開発当初から拡張可能なプログラミング言語となるよう設計されていた．
言語そのものの大半がLispの関数の集合体であり，
それらはユーザ自身の定義によるものと何も違わない．
それどころかLispの関数はリストとして表現できるが，リストはLispのデータ構造なのだ．
このことは，ユーザがLispコードを生成するLisp関数を書けるということだ．

いいLispプログラマはこの可能性を利用する方法を知らなければならない．
そのための方法は普通，\emph{マクロ}と呼ばれる一種のオペレータを定義してみることだ．
マクロの理解は，正しいLispプログラムを書くことから
美しいLispプログラムを書くことへ移行する際の最も重要なステップの一つだ．
入門的なLisp本に載っているのはマクロの大雑把な外観程度：
マクロとは何かの説明と，
ユーザがマクロを使えば可能になる奇妙で素晴らしいことのヒントとなる幾つかの例だ．
ここではそういった奇妙で素晴らしい事柄に特に注意してみる．
この本の狙いの一つは，そういったユーザ達がマクロに関する経験から
今に至るまでに学ばなければならなかったことを一箇所にまとめることだ．

無理もないことだが，入門的なLisp本はLispと他のプログラミング言語との違いを強調しない．
そういった本は（大抵）Pascal用語でプログラムを考えるよう教育されてきた生徒達に
メッセージを伝えなければならない．
「LispのdefunはPascalの手続き定義に似ているが，
実際は関数オブジェクトを作るコードを生成するプログラムを書くプログラムであり，
第1の引数として与えられたシンボルを名札に使うのだ．」
と説明しても，混乱を招くばかりだろう．

この本の目的の一つは，Lispと他のプログラミング言語との違いは何かを説明することだ．
私は当初から，他の点がみな同じだったらCやPascalやFortranではなく
Lispでプログラムを書いた方がずっといいということは分かっていた．
これは単なる好みの問題ではないことも分かっていた．
しかし実際にLispが何らかの点でよりいいプログラミング言語だと主張するなら，
それがなぜかを説明できるようにした方がいいことに気が付いたのだ．

誰かがLouis Armstrongにジャズとは何かと尋ねたとき，彼はこう答えた．
「ジャズとは何かが人に聞かないと分からないんだったら，
分かるようにはならないだろうね．」
しかし彼はある方法で確かにその質問に答えた：
彼は人々にジャズとは何かを\emph{示した}のだった．
それがLispの力を説明する唯一の方法だ\wadash
他のプログラミング言語では困難だったり，不可能な技をやってみせることだ．
プログラミングに関する本の大半が\wadash Lispプログラミングの本さえ\wadash
どんなプログラミング言語でも書けるような題材を扱っている．
\emph{On Lisp}は，Lispでのみ書けるような類のプログラムを主に扱う．
拡張性，ボトムアップ・プログラミング，インタラクティブな開発，
ソースコードの変換，埋め込み言語\wadash Lispの長所が現れるのはそういった所だ．

もちろん原則的には，Turing機械と等価なプログラミング言語はみな
他のプログラミング言語と同じ作業が可能だ．
しかしそういった能力は，プログラミング言語が目的とするものではない．
原則的には，プログラミング言語でできることはみなTuring機械でもできる．
しかし実際には，Turing機械のプログラミングは手間をかけるに値することではない．

だから私が「これは他のプログラミング言語では不可能なことのやり方に
ついての本だ」と言うとき，数学的な意味で「不可能」だと言うのではなく，
プログラミング言語に関わる意味でそう言っているのだ．
つまり，この本の中のプログラムの幾つかをCで書かなければならないなら，
始めにCでLispコンパイラを書くことで目的を達しても同じなのだから．
例えばCでPrologを埋め込み言語にしてみる\wadash
それにかかる手間は想像がつくだろうか？
第24章では，180行のLispコードを使ってその方法を示す．

しかし，ただLispの能力のデモンストレーションをする以外にもっとやりたいことがある．
\emph{なぜ} Lispは他と違っているのかも説明したい．
これは実は微妙な問いだ\wadash
非常に微妙な問いなので「記号演算(Symbolic computation)」
などという言葉を答えにすることはできない．
私がこれまでに学んだことはできる限り明快に説明するよう試みた．
%}}}
\subsection{この本の方針}   %{{{
関数はLispプログラムの基礎なので，この本の最初の幾つかの章では関数を扱う．
第2章では，Lispの関数とは何かということと，関数のもたらす可能性を説明する．
第3章では，Lispプログラムでの主要なプログラミング・スタイルである
関数プログラミングの長所について議論する．
第4章では，Lispの拡張のための関数の使い方を示す．
そして第5章では，別の関数を返す関数を使って定義できる，新たな種類の抽象化を示唆する．
最後に第6章では，伝統的なデータ構造の代わりに関数を使う方法を示す．

この本の残りの章では，関数よりもマクロの方を多く扱う．
マクロにはより多くの注意を払った．
一つにはマクロにはもっと語るべきことがあるからで，
また書籍では今まで十分に説明されていなかったからでもある．
第7--10章では，マクロに関するテクニックについての完全な手引きを与える．
そこまでで，熟練Lispプログラマがマクロについて知っていること\wadash
作用の仕組み，定義方法，テスト，デバッグ，使うべきときとそうでないときの区別，
マクロの主要な種類，マクロ展開を生成するプログラムの書き方，
マクロのスタイルとLispのスタイルとの一般的な違い，
マクロに影響するそれぞれの独特な問題を発見し，修正する方法\wadash
は全て理解できるだろう．

この手引きに続き，第11--18章ではマクロによって可能になる強力な抽象化を幾つか示す．
第11章では，コンテキストを形成したり，
繰り返しや条件分岐を実現する古典的なマクロの書き方を示す．
第12章では，一般化された変数への作用におけるマクロの役割を説明する．
第13章では，マクロを使い，行うべき計算をコンパイル時にやってしまうことで
プログラムを速く走らせる方法を示す．
第14章ではアナフォリック（anaphoric）マクロを導入する．
これはプログラム内で代名詞を使うことを可能にする．
第15章では，マクロを使って第5章で定義された関数ビルダに
便利なインタフェイスを提供する方法を示す．
第16章では，Lispにユーザのプログラムをユーザのために書かせるために使われる，
マクロを定義するマクロの使い方を示す．
第17章ではリードマクロ（read macro）について，
第18章では構造化代入（destructuring）のためのマクロについて議論する．

第19章からはこの本の第4部\wadash 埋め込み言語のために割かれた部分が始まる．
第19章では，2種類の同じ働きのプログラムを示すことでその話題を導入する．
それはデータベースに対する問い合わせ（クエリ）に答えるものだが，
最初はインタプリタによって実装されたものを，
そして次には本物の埋め込み言語として実装されたものを示す．
第20章では，Common Lispプログラムに，
計算の残りを表すオブジェクトである継続（continuation）の概念を導入する方法を示す．
継続は非常に強力なツールで，複数プロセスと非決定的選択の両方の実装に使える．
これらの制御構造をLispに埋め込む方法は，それぞれ第21,~22章で議論する．
非決定性を使えば予知能力を持っているかのようなプログラムが書けるようになるが，
これは不思議な能力の概略のように思えていることだろう．
第23,~24章では，
非決定性がその触れ込みに違わないことを示す埋め込み言語を2個取り上げる：
完全なATNパーサと埋め込みPrologだが，コードは全部で200行余り\note{200lines}になる．

これらのプログラムが短いという事実は，それ自身の中身は何もないということを表している．
不可解なコードを書くことに頼ったなら，200行で可能なことについては何も分からない．
これらのコードが短く済むのは，プログラミング上のトリックに頼ったからではなく，
Lispが本来意図していた使い方に従って書かれているからなのだ．
それこそが重要な点だ．
第23,~24章の中核は，ATNパーサを1ページ分のコードで実装したり，
Prologを2ページ分のコードで実装する方法ではない．
最も自然なLispによる実装によれば，それらのプログラムは単にその短さで済むという事実だ．
その後の章で使われる埋め込み言語は，最初のポイント二つ\wadash
Lispはボトムアップ・デザインのための自然な言語であることと，
ボトムアップ・デザインはLispの自然な使用方法であること\wadash
の例に基づく証明を与える．

この本のまとめは，オブジェクト指向プログラミングの議論と，
特にCLOS (the Common Lisp Object System)だ．
この話題を最後に取っておくことで，オブジェクト指向プログラミングがLisp内に既にある
考え方の延長に位置するということを一層はっきりと理解できる．
それは\emph{Lispで}構築できる数多くの抽象化構造のうちの一つなのだ．

注釈は\pageref{chap:note}ページから始まり，参考文献案内，
追加または代替用のコードや，その場には直接関係のないLispの側面の説明も含む．
注釈は\textdagger を肩に乗せて示したby訳者．
またパッケージに関する付録（\pageref{chap:package}ページ）もある．

ニューヨークのツアーが世界の文化の大半のツアーになりうるのと同様，
プログラム可能なプログラミング言語としてのLispの学習は
Lispテクニックの大部分のスケッチになる．
ここで説明されたテクニックの大半はLispコミュニティに知られているが，
今までどこにも書かれていなかったことも多い．
またマクロの適切な役割や変数キャプチャの本質といった話題は，
多数の熟練Lispプログラマたちもおぼろげにしか理解していなかった．
%}}}
\subsection{例} %{{{
Lispはプログラミング言語の一族だ．
そのうちCommon Lispはこの先ずっと広く使われる方言(dialect)だろうから，
この本の例の大半はCommon Lispで書かれている．
この言語は元々1984年にGuy Steeleの本\emph{Common Lisp: the Language}
(\textsf{CLtL1})によって定義されたものだ．
この定義は1990年に第2版(\textsf{CLtL2})の出版によって改訂された\note{CLtL2}．
今度は将来の\textsf{ANSI}標準がその役目を引き継ぐことだろう
\footnote{訳注：1996年にANSI Common Lisp（アメリカ公式標準）制定．
GCL，Clisp，CMUCL，SBCLなどフリーの実装あり．}．

この本には，式一個から正しく動作するPrologの実装まで，数百の例が載っている．
この本のコードのうち，
可能なものはみな全てのヴァージョンのCommon Lispで動作するように書かれている．
\textsf{CLtL1}の実装にない機能を必要とするわずかな例は，本文中にその旨を明記してある．
後半の章にはSchemeによる例も幾つかある．
これらもはっきりと分かるようにしてある．

コードは\verb|endor.harvard.edu|のanonymous \textsf{FTP}の
\verb|pub/onlisp|ディレクトリから手に入る．
質問やコメントは\verb_onlisp@das.harvard.edu_に送ってほしい．
%}}}
\subsection{謝辞}   %{{{
{\narrowbaselines\vskip.5\baselineskip
\noindent
While writing this book I have been particularly thankful for the help of Robert
Morris. I went to him constantly for advice and was always glad I did. Several
of the examples in this book are derived from code he originally wrote, including
the version of for on page 127, the version of aand on page 191, match on
page 239, the breadth-first true-choose on page 304, and the Prolog interpreter
in Section 24.2. In fact, the whole book reflects (sometimes, indeed, transcribes)
conversations I've had with Robert during the past seven years. (Thanks, rtm!)

\hspace*{2ex}I would also like to give special thanks to David Moon, who read large parts
of the manuscript with great care, and gave me very useful comments. Chapter 12
was completely rewritten at his suggestion, and the example of variable capture
on page 119 is one that he provided.

\hspace*{2ex}I was fortunate to have David Touretzky and Skona Brittain as the technical
reviewers for the book. Several sections were added or rewritten at their sugges-tion.
The alternative true nondeterministic choice operator on page 397 is based
on a suggestion by David Toureztky.

\hspace*{2ex}Several other people consented to read all or part of the manuscript, including
Tom Cheatham, Richard Draves (who also rewrote alambda and propmacro
back in 1985), John Foderaro, David Hendler, George Luger, Robert Muller,
Mark Nitzberg, and Guy Steele.

\hspace*{2ex}I'm grateful to Professor Cheatham, and Harvard generally, for providing the
facilities used to write this book. Thanks also to the staff at Aiken Lab, including
Tony Hartman, Janusz Juda, Harry Bochner, and Joanne Klys.

\hspace*{2ex}The people at Prentice Hall did a great job. I feel fortunate to have worked
with Alan Apt, a good editor and a good guy. Thanks also to Mona Pompili,
Shirley Michaels, and Shirley McGuire for their organization and good humor.

\hspace*{2ex}The incomparable Gino Lee of the Bow and Arrow Press, Cambridge, did the
cover. The tree on the cover alludes specifically to the point made on page 27.

\hspace*{2ex}This book was typeset using \LaTeX, a language written by Leslie Lamport atop
Donald Knuth's \TeX, with additional macros by L. A. Carr, Van Jacobson, and
Guy Steele. The diagrams were done with Idraw, by John Vlissides and Scott
Stanton. The whole was previewed with Ghostview, by Tim Theisen, which is
built on Ghostscript, by L. Peter Deutsch. Gary Bisbee of Chiron Inc. produced
the camera-ready copy.

\hspace*{2ex}I owe thanks to many others, including Paul Becker, Phil Chapnick, Alice
Hartley, Glenn Holloway, Meichun Hsu, Krzysztof Lenk, Arman Maghbouleh,
Howard Mullings, Nancy Parmet, Robert Penny, Gary Sabot, Patrick Slaney, Steve
Strassman, Dave Watkins, the Weickers, and Bill Woods.

\hspace*{2ex}Most of all, I'd like to thank my parents, for their example and encouragement;
and Jackie, who taught me what I might have learned if I had listened to them. \\

この本を読むのはきっと楽しいと思う．
私は，知っているプログラミング言語のうちでLispが一番好きだ．
それはただLispが一番美しいからだ．
この本は，最高にLispっぽいLisp (Lisp at its lispiest)についての本だ．
この本を書くのは楽しかった．
その感じが行間に流れていたら嬉しい．}
\begin{flushright}\emph{Paul Graham}\end{flushright}
%}}}
%}}}
    \newpage\MYtableofcontents\newpage
\section{拡張可能なプログラミング言語}  %{{{
遠くない昔，Lispは何のためのプログラミング言語かと尋ねれば，
多くの人が「人工知能(\textsf{AI})用のプログラミング言語」と答えただろう．
実際はLispと\textsf{AI}との関係は歴史の偶然に過ぎない．
Lispの開発者はJohn McCarthyで，彼は「人工知能」という言葉の提唱者でもある．
彼の生徒と同僚達は彼らのプログラムをLispで書いた．
それがLispが\textsf{AI}用のプログラミング言語と言われ出したきっかけだ．
このつながりは広く取り上げられ，1980年代の短い\textsf{AI}ブームの間に
大変な程繰り返されたので，ほとんど迷信のようになってしまった．

幸運なことに，\textsf{AI}だけがLispの目的でないとの言葉が広まり始めた．
最近のハードウェアとソフトウェアの進歩のおかげで，Lispは商業的にも成功し始めた：
今では最高のUNIX系テキストエディタGNU Emacs，
業界標準のデスクトップ\textsf{CAD}ソフトAutocad，
そして先駆的ハイエンド出版ソフトInterleafで使われている．
これらのプログラムでのLispの使われ方は\textsf{AI}とは何も関係ない．

Lispが\textsf{AI}用プログラミング言語でないのなら，いったい何なのか？
Lispを取り巻く仲間でそれを判断するのでなく，言語そのものを見てみよう．
他のプログラミング言語でできないことのうち，Lispには何ができるか？
Lispの最も特徴的な性質の一つは，Lispによって書かれているプログラムに合わせて
Lispを仕立てることができる点だ．
LispそのものがLispのプログラムの一つであり，
Lispのプログラムはリストとして表現できるが，リストはLispのデータ構造なのだ．
これら2個の原則が相俟って，
どのユーザも組み込みのものと区別の付かないオペレータをLispに追加できることになる．
\subsection{進化によるデザイン} %{{{
Lispではユーザに独自のオペレータを定義する自由があるので，
Lispを必要なプログラミング言語にきっちり仕立てることができる．
ユーザがテキストエディタのプログラムを書いているのなら，
Lispをテキストエディタを書くための言語に変えることができる．
また\textsf{CAD}ソフトのプログラムを書いているのなら，
Lispを\textsf{CAD}ソフトを書くための言語に変えることもできる．
そしてどんなプログラムを書くかまだ確かでないなら，Lispで書いておくのが安全な賭けだ．
それがどんな種類のプログラムになったとしても，それを書いている間に，
Lispは\emph{その種類の}プログラムを書くためのプログラミング言語に進化していることだろう．

どんなプログラムを書くかまだ確かでないなら？
人によってはこの文は奇妙に響くだろう．
その人は
(1)~これからやることを注意深く計画し，そして
(2)~それを実行する，というモデルとの不愉快な対照を目にしたことになる．
このモデルによれば，プログラムのすべき動作を決める前にプログラムを書くことを
Lispが勧めるとすれば，それは的外れな考え方を勧めているに過ぎないことになる．

さて，全くそんなことはない．
「計画－実装」方式もダム建設や侵略作戦の決行にはいい方法だったが，
人々の経験によればプログラムを書くのにいい方法だったかどうかは定かでない．
なぜか？~きっとそれは，コンピュータは大変正確だからだ．
きっとプログラムにはダムや侵略作戦よりもヴァリエーションが多いからだ．
または「余分」ということに関する古い概念とソフトウェア開発に類似点が
ないせいで，古い方式が機能しないことによるのだろう：
ダムが30\%余分なコンクリートを使っていても，それは間違いなのかどうかぎりぎりの所だ．
しかしプログラムが30\%余分な動作をしていたら，それは\emph{間違い}だ．

古い方式が失敗に終わるのがなぜかを言うのは難しいかもしれないが，
それは確かに失敗し，結果は誰の目にも明らかだ．
ソフトウェアが期日通りに完成したことがあるだろうか？
熟練プログラマは，どれ程慎重にプログラムの計画を立てても，
プログラムを書き始めると，必ず計画にどこか不完全な点が見つかることを知っている．
計画が望みのない程まで間違っていることもある．
しかし「計画－実装」方式の犠牲者のほとんどはその基礎の健全さを疑おうとはしない．
代わりに彼らは人間の失敗を責める：
「もう少しいい展望の下に計画を立ててさえいたら，こんな問題は全て避けられただろう．」
最高レベルのプログラマでさえ実装となれば問題に突き当たるのだから，
人々が必ずそれだけの展望を持つことを望むのはどうやら無茶のようだ．
おそらく「計画－実装」方式は，
我々の持つ限界により適した別のアプローチで置き換えることができるだろう．

適切なツールがあるならば，プログラミングへの別のアプローチが可能だ．
なぜ実装の前に計画を立てるのか？
プロジェクトの立案にどっぷり浸かり込むことの大きな危険性は，
自らを困難に追い込んでしまう可能性がある点だ．
もっと柔軟なプログラミング言語があれば，この心配を減らせるのでは？
まさにその通りだ．
Lispの柔軟性は全く新しいプログラミングのスタイルを生み出した．
Lispにおいては，計画の大部分を立てるのはプログラムを書きながらでいい．

なぜ後知恵が浮かぶのを待つのか？
Montaigneが気付いたように，考えを明確にするにはそれを書き下ろそうとすることが一番だ．
自らを困難に追い込んでしまうとの心配からひとたび解放されれば，
この可能性を最大限に活用できる．
プログラムを書きながら計画を立てる能力には二つの重要な結果につながる：
まず，プログラムを書くのにかかる時間が短くなる．
それは計画を立てると同時にプログラムを書くと，
注意を集中することで本当のプログラムが出来上がるからだ．
そしてその方法で出来たプログラムはよりいいものであると分かるだろう．
それはプログラムの最終デザインは必ず進化の産物だからだ．
プログラムの目的を探す間，間違っていた部分を，
明らかになったその場で必ず書き直すという原則を守る限り，
最後に出来上がったものは，
あらかじめ計画に数週間を費やした場合よりも優美なプログラムになるだろう．

Lispが多目的なプログラミング言語だからこそ，
この種のプログラミングが実用的な代替手段になる．
事実，Lispの持つ最大の危険はLispがユーザに悪影響を与えるかもしれないことだ．
一度Lispをしばらく使うと，プログラミング言語とアプリケーションとの相性に敏感になりすぎ，
元々使っていたプログラミング言語に戻っても，
これでは必要な柔軟性が手に入らないという思いに常に囚われるようになりかねない．
%}}}
\subsection{ボトムアップ・プログラミング}   %{{{
プログラムの機能的要素は余り大きくなるべきでないというのが，
プログラミング・スタイルの長年の原則だ．
プログラムの構成要素が，読めば理解できる状態を超えて肥大化するなら，
それは複雑さの固まりに成り果て，（大都市が流れ者を隠すように）簡単にエラーを覆い隠す．
そういうソフトウェアは読み辛く，テストし辛く，デバッグし辛い．

この原則に従い，大規模なプログラムは部品へと分割しなければいけない．
またプログラムが大規模であればある程，さらに分割しなければいけない．
プログラムを分割する方法とは何か？
伝統的アプローチは\emph{トップダウン・デザイン}と呼ばれる：
「このプログラムの目的はこれらの7個だから，
プログラムを7個の主要サブルーチンに分割することにする．
1個目のサブルーチンはこれら4個のことを行わなければいけないから，
それ自身のサブルーチンが今度は4個になり，\dots」といった具合だ．
このプロセスはプログラム全体が適切なバラバラ状態\wadash
全ての部分が意味のある仕事を行えるだけの大きさでありながら，
単一のユニットとして理解できる位小さくなった状態\wadash になるまで続く．

熟練Lispプログラマがプログラムを分割する方法は違っている．
トップダウン・デザインと同様，彼らには従う原則があり，
それは\emph{ボトムアップ・デザイン}\wadash
プログラミング言語を問題に適するように変えていく\wadash と呼ばれる．
Lispでは，プログラムをただプログラミング言語に従って書くことはしない．
プログラミング言語を自分の書くプログラムに向けて構築するのだ．
プログラムを書いているとき，
「Lispに○△のオペレータがあればなあ．」と思うことがあるかもしれない．
そうしたらそれを書けばいい．
後で，新しいオペレータの使用が
プログラムの別の部分のデザインを簡潔にまとめることにつながったと気付くだろう．
そういった感じでプログラミング言語とプログラムは共に進化する．
交戦中の2国間の国境のように，二つの境界は何度も書き直される．
それが落ち着くのは，
山や川（ここではユーザの問題の持つ自然な境界）に辿り着いたときだ．
最終的には，ユーザのプログラムではプログラミング言語がそのために
設計されたかのような見掛けになる．
そしてプログラミング言語とプログラムが相性良く落ち着いたとき，
ユーザは明快で小規模で効率的なコードを手にする．

ボトムアップ・デザインは，同じプログラムをただ別の順番で
書くだけのことではないということは，強調する価値がある．
ボトムアップで作業すると，大抵別のプログラムが出来上がる．
単一の一体となったプログラムではなく，
抽象的なオペレータを持つ大規模なプログラミング言語と，
それで書かれた小規模なプログラムが出来るのだ．
ユーザは敷石ではなく，高いアーチを手にする．

典型的なコードでは，単なる簿記に過ぎない部分を一度抽象化すると，残るものはずっと短い．
プログラミング言語を高く構築すればする程，頂点からそこに至るまでの道のりは短くなる．
これは幾つかの長所をもたらす：
\begin{enumerate}
\item プログラミング言語に仕事を任せることで，
    ボトムアップ・デザインでは小規模で機敏なプログラムが生まれる．
    短いプログラムは多数の構成要素に分割する必要がない．
    そして構成要素が少ないということは，
    プログラムが読み易く修正し易いものだということだ．
    また構成要素が少ないということは，構成要素同士の連結も少ないということなので，
    そこでエラーが起きる可能性も少ない．
    工業デザイナが機械の可動部分を減らそうと努力するのと同様に，
    熟練Lispプログラマはボトムアップ・デザインを使って
    プログラムの大きさと複雑さを減らそうとする．
\item ボトムアップ・デザインはコードの再利用を促進する．
    プログラムを二つ以上書くとき，
    最初のプログラムのために書いたユーティリティの多くは他のプログラムでも有用になる．
    ユーティリティの大規模な基盤を手にしてしまえば，新しいプログラムを書く手間は，
    Lispそのもので書かなければならないときにかかる手間の数分の一に過ぎない．
\item ボトムアップデザインはプログラムを読み易くする．
    この種の抽象化のインスタンスは，読む人に汎用オペレータを理解するよう要求する．
    機能的抽象化のインスタンスは，
    読む人に特殊目的のサブルーチンを理解するよう要求する
    \footnote{「でもあんたのユーティリティを全部理解しないことには，
    プログラムが読めなくなるじゃないか．」
    そういった言葉は大抵誤りだ．なぜかについては，第4.8節を参照．}．
\item ユーザにコード内のパターンに常に関心を払うようにさせる．
    ボトムアップでの作業はプログラムのデザインに関するアイディアを
    明確にするのに役立つ．
    一つのプログラムの中で種類の違う2個の構成要素が形の上で似ているなら，
    類似性に気付くよう促されるし，
    おそらく単純な方法でプログラムをデザインし直すよう促されるだろう．
\end{enumerate}
ある程度までは，ボトムアップ・デザインはLisp以外のプログラミング言語でも可能だ．
ライブラリ関数を見ればそこには必ずボトムアップ・デザインの例がある．
しかしLispはこの点に関してずっと幅広い力を与え，
プログラミング言語にそれに比例してLispのスタイルの中で
大きな役割を演じるよう促す\wadash その役割が余り大きいので，
Lispはただのプログラミング言語の一つではなく，
全く違ったプログラミング方法になっている．

このスタイルの開発は，幾つかの小規模グループによって書ける程度のプログラムに
適しているというのは確かに真実だ．
しかし同時に，このスタイルは小規模グループのなし得ることの限界を拡張する．
Frederick Brooksが「人月の神話」\kern0pt (\emph{The Mythical Man-Month})%
\note{myth}の中で示唆したのは，プログラマのグループの生産性は
その規模に対して線形には増大しないということだった．
グループのサイズが増大するにつれ，個々のプログラマの生産性は低下してゆく．
Lispプログラミングの経験はこの法則を表現するためのより素敵な方法を提案する：
グループのサイズが減少するにつれ，個々のプログラマの生産性は向上してゆく．
相対的に小規模なグループが勝利を収める．
理由は単純，小さいから．
小規模グループがLispによって可能になるテクニックを活用するとき，
完全な勝利が待っている．
%}}}
\subsection{拡張可能なソフトウェア} %{{{
Lispスタイルのプログラミングは，ソフトウェアが複雑さを増すにつれ重要性を増してきた．
今時のユーザからのソフトウェアへの要求は余りに多く，
プログラマにはほとんど予想しきれない．
ユーザ自身も要求の全てを予想することができなくなっている．
しかしユーザの望みを完璧に叶えるソフトウェアをプログラマが供給できなくとも，
プログラマには拡張できるソフトウェアを供給することはできる．
プログラマは自分のソフトウェアをただのプログラムからプログラミング言語に転換し，
技術の高いユーザは必要な付加的機能をその上に作り上げるようになる．

ボトムアップ・デザインは拡張可能なプログラムに自然につながっていく．
ボトムアップ・プログラムの最も単純なものは，2層から成る：
プログラミング言語とプログラムだ．
複雑なプログラムも一連の層として書き上げることができる．
それぞれの層は1段下の層に対してプログラミング言語として機能する．
この方針が最上層まで貫かれれば，その層がユーザの使うプログラミング言語となる．
そのようなプログラムではあらゆるレベルで拡張が可能になっていて，
伝統的なブラックボックスとして書かれ，後から拡張性を付け加えたシステムよりも
遥かにいいプログラミング言語が出来上がることが多い．

X~Windowsと\TeX はこの原則に基づくプログラムの古い例だ．
1980年代には高性能のハードウェアによってLispを自らの拡張言語とする
新世代のプログラムが可能になった．
その最初は有名なUNIXのテキストエディタ，GNU Emacsだ．
次はAutocadで，これはLispを拡張言語とする大規模商用製品としては初になる．
1991年にはInterleafの新ヴァージョンがリリースされたが，
それはLispを拡張言語に使っていただけではなく，かなりの部分がLispで実装されていた．

Lispは拡張可能なプログラムを書くためには素晴らしくいいプログラミング言語だ．
それはLisp自身が拡張可能なプログラムであるからだ．
Lispの拡張性をユーザにも渡すようなLispプログラムを書けば，
実質的には何もせずに拡張言語が出来たことになる．
そしてLispでLispプログラムを拡張することと，
伝統的なプログラミング言語でそれを行うこととの違いは，
誰かに直接会うことと手紙でやりとりすることとの違いのようなものだ．
外部プログラムへのアクセス手段を提供することだけで
拡張可能になったプログラムでは，
既定のチャンネルを通じて連絡し合う二つのブラックボックスがせいぜいだ．
Lispでは，拡張機能は背後にあるプログラム全体に直接アクセスできる．
これはユーザにプログラムのあらゆる部分へのアクセスを
与えなければならないということではなく，
ただアクセスを与えるか与えないかの選択肢があるというだけのことだ．

このような部分的アクセスがインタラクティブな環境と結びつくと，最高の拡張性が得られる．
自分のプログラムの拡張機能の基礎として使えるようなプログラムは，
どれもかなり大規模になりがちだ．
おそらく規模が大きすぎて全体的なイメージが掴めない程だろう．
何か不確かな点があるときどうなるだろう？
そのとき元のプログラムがLispで書かれていれば，
それをインタラクティブに調べることができる：
データ構造を調査できる．関数を呼び出せる．ソースコードを読むことさえできる．
この種のフィードバックにより，確かな自信を持ってプログラムを製作できる．
思い切った拡張機能を書けるし，しかもそれが素早くできる．
インタラクティブな環境は常にプログラミングを容易なものにしてくれるが，
拡張機能を書いているとき程それが有り難いときはない．

拡張可能なプログラムは諸刃の剣だが，
最近の経験によればユーザはただの剣より諸刃の剣の方を好む．
どんな危険性が備わっていようとも，
拡張可能なプログラムの方が勝るようだ．
%}}}
\subsection{Lispの拡張} %{{{
Lispに新しいオペレータを加えるには2通りの方法がある: 関数とマクロだ．
Lispではユーザの定義した関数は組み込み関数と同じ地位を占める．
もし\verb@mapcar@の変種が新しく必要になったら，それを自分で定義し，
\verb@mapcar@を使うのと同じようにそれを使うことができる．
例えば，ある関数が\verb@1@から\verb@10@までの整数に適用されたときに
それが返す値のリストが必要なら，
新しいリストを作ってそれを\verb@mapcar@に渡すことができる：
\begin{verbatim}
(mapcar fn
        (do* ((x 1 (1+ x))
              (result (list x) (push x result)))
          ((= x 10) (nreverse result))))
\end{verbatim}
しかしこの方法は格好悪いし非効率だ\footnote{これは新しいCommon Lispの
数列マクロを使ってもっとエレガントに書くこともできる．
しかしこれらのマクロはLispそのものの拡張となっているので，結局は同じことだ．}.
代わりに新しい対応関数\verb@map1-n@（54ページ参照）を定義し，
それを次のように呼び出せばいい：
\begin{verbatim}
(map1-n fn 10)
\end{verbatim}

関数を定義するのは比較的真っ当な方法だ．
マクロは新しいオペレータのさらに一般的な
（しかし余り理解されていない）定義方法を提供する．
マクロはプログラムを書くプログラムだ．
この文には非常に深い意味が込められている．
そしてその探求はこの本の主目的の一つなのだ．

マクロを注意して使えば驚異的に明確でエレガントなプログラムができる．
これらの宝石のようなプログラムは，何もせずに得られたわけではない．
最後にはマクロは世界で一番自然なものに思えるだろうが，最初は理解が難しい．
これはマクロが関数よりも一般的で，書くときに注意すべきことが多いせいもある．
しかしマクロの理解が難しい大きな理由は，それが全く異質な(\emph{foreign})ものだからだ．
Lispのマクロのようなものを持つ言語は他にない．
だからマクロについて学ぶと，
他のプログラミング言語からうっかり引き継いだ先入観を振り捨てることに
つながるかもしれない．
その中の主要なものは，死後硬直に悩まされるものとしてのプログラムという概念だ．
なぜデータ構造が流動的で変更可能であるべきなのに，プログラムはそうでないのだろうか？
Lispではプログラムがデータ\emph{である}のだ．
しかしこの事実の持つ意味をモノにするには暫く時間がかかる．

マクロに慣れるのに暫く時間がかかっても，それは努力に見合うことだ．
繰り返しのようなありふれた用途でも，
マクロはプログラムを目覚ましく小型できれいなものに変える．
ここで，あるプログラムがコード本体を\verb@x@について\verb@a@から\verb@b@まで
繰り返さなければならないとしよう．
Lisp組み込みの\verb@do@はもっと一般的な目的のためのものだ．
それを単純な繰り返しに使うと一番読み易いコードにはならない：
\begin{verbatim}
(do ((x a (+ 1 x)))
    ((> x b))
  (print x))
\end{verbatim}
代わりにこうするだけでいい：
\begin{verbatim}
(for (x a b)
  (print x))
\end{verbatim}
マクロがこれを可能にする．
6行のコードで（154ページ参照）\verb@for@文をこのプログラミング言語に追加できる．
そしてそれは初めからあった構文のように機能する．
そして後の章で見るように，\verb@for@の実装はマクロでできることの手始めでしかない．

Lispの拡張で一度に使えるのは関数やマクロ1個ずつに限られるわけではない．
必要とあればあるプログラミング言語全体をLispの上に構築し，
それを使ってプログラミングすることもできる．
Lispはコンパイラやインタプリタを書くのに最適のプログラミング言語だが，
新しいプログラミング言語を定義する別の方法を提供する．
その方がしばしばエレガントだし，労力が少なく済むのは確かだ：
それはLispを修正して新しいプログラミング言語を定義する方法だ．
そうすればLispの機能のうち新しいプログラミング言語でも変更せずに使える部分
（例えば算術演算や\textsf{I/O}）はそのまま利用でき，
異なっている部分（例えば制御構造）だけ実装すればいい．
このように実装されたプログラミング言語を\emph{埋め込み言語}と呼ぶ．

埋め込み言語はボトムアップ・プログラミングの自然な帰結だ．
Common Lispには既に幾つか例がある．
一番有名な\textsf{CLOS}については後の章で議論する．
しかし自分だけの埋め込み言語を定義することもできる．
自分のプログラムに適した埋め込み言語を作ることができるが，
それがLispとかけ離れたようなものになってもいい．
%}}}
\subsection{なぜ（またはいつ）Lispか}   %{{{
これらの新たな可能性は魔法の要素たった1個から生まれる訳ではない．
この点を見れば，Lispはアーチのようなものだ．
楔形の石(voussoirs)のうち，どれがアーチを支えているのか？
これは質問そのものが誤っている：どの石もアーチを支えているのだ．
アーチと同様，Lispは組み合わさった機能の集合体だ．
それらの幾つかをここで挙げることができる\wadash
動的メモリ割り当てとガーベジ・コレクション，実行時型指定，
オブジェクトとしての関数，リストを生成する組み込みパーサ，
リストとして表現されたプログラムを受け付けるコンパイラ，
インタラクティブな環境等々\wadash
しかしどの一つをとってもLispの持つ力の理由にはならない．
LispプログラミングをLispプログラミングたらしめているのは，そのコンビネーションだ．

過去20年でプログラミングの方法は変化した．
インタラクティブな環境，動的リンク，オブジェクト指向プログラミングまで\wadash
これらの変化の多くは，Lispの柔軟性を幾分かでも他のプログラミング言語に与えようとする
細切れの試みだった．
アーチの喩えは，それらがどれ程成功を収めたかを示唆している．

LispとFortranが現存するプログラミング言語のうち最も古いものだということは，
よく知られている．
おそらくもっと意味のある事実は，それらはプログラミング言語のデザインの思想のうち
対極にあるものを代表しているということだ．
Fortranはアセンブリ言語からの進歩として開発された．
Lispはアルゴリズムを表現するプログラミング言語として開発された．
そういった異なる意図は，大きく異なるプログラミング言語を生んだ．
Fortranはコンパイラ開発者の人生を楽にしてくれる．
Lispはプログラマの人生を楽にしてくれる．
それ以来，大抵のプログラミング言語は二つの極の間のどこかに位置するものだった．
そしてFortranとLispは真ん中に向かって歩み寄ってきた．
Fortranは今ではずいぶんAlgolに似てきたし，
Lispは若かりし頃の無駄な習慣を幾つか諦めた．

最初のFortranとLispは一種の戦場のようなものを定義した．
片方では鬨の声は「効率～！（実装は辛すぎる）」で，
もう片方では鬨の声は「抽象化～！（商用ソフトではあり得ない）」だ．
古代ギリシャの戦争の結果を神々が高みから決めたように，
この戦の結果はハードウェアによって決められるようになっている．
年を追うごとに情勢はLisp側に有利になってきているようだ．
今ではLispに対する議論は，1970年代初頭にアセンブリ言語プログラマ達が
高水準プログラミング言語に対して仕掛けた議論に非常に似てきた．
今や問いは\emph{なぜLispか？}ではなく\emph{いつLispか？}になっている．
%}}}
%}}}
\section{関数}  %{{{
LispはLispプログラムを作り上げるブロックであり，Lispを作り上げるブロックでもある．
大抵のプログラミング言語では，
オペレータ \verb@+@ はユーザの定義した関数と全く違ったものになっている．
しかしLispは関数の適用という，
プログラムによって行われる全ての計算を説明する単一のモデルを持っている．
Lispのオペレータ \verb@+@ は1個の関数であり，
ユーザ自身が定義できる関数と全く同じだ．

事実，特殊オペレータと呼ばれる少数のオペレータを除き，Lispの中核はLispの関数の集合だ．
この集合に追加するのをためらう必要があるだろうか？
そんなことはない：Lispがこれをしてくれたら，
と思うことがあればそれを自分で書くことができ，
その新しい関数は組み込みのものと全く同じように扱われるだろう．

この事実はLispプログラマにとって重要な結論をもたらす．
これは新しい関数のどれもが，Lispへの追加とも，
特定のアプリケーションの一部とも考えられるということだ．
熟練Lispプログラマの典型的なやり方は，両方を幾らかずつ書き，
プログラミング言語とアプリケーションが完璧に噛み合うまで二つの境界を調整することだ．
この本はプログラミング言語とアプリケーションを相性よくまとめる方法について
書かれたものだ．
この目標に向かって行うことはみな関数に依存するのだから，
関数から始めるのが自然なやり方だ．
\subsection{データとしての関数} %{{{
Lispの関数を他から際だたせているのは2個の特徴だ．
1個目は，上で述べたようにLispそのものが関数の集合だということ．
このことはLispに自分で作った新しいオペレータを追加できるということだ．
関数に関して知るべきもう一つの大事なことは，関数はLispのオブジェクトだということだ．

Lispは，他のプログラミング言語で目にするようなデータ型をほとんど提供する．
整数も浮動小数点数もあれば，文字列，配列，構造体等もある．
しかしLispはあるデータ型を提供するが，これは最初は衝撃的かもしれない：関数だ．
ほとんど全てのプログラミング言語が何らかの形で関数や手続きを提供する．
Lispがそれらをデータ型として提供するとはいったいどのような意味なのだろう？
それはLispでは関数を使って，
他の親しみ深いデータ型（整数等）でやろうと思うことが全てできるということだ：
実行時に新しくオブジェクトを作り，変数や構造体の中に保持し，
他の関数に引数として渡し，結果として返す，等．

実行時に関数を生成し，それを返す能力は特に便利だ．
これは「あるコンピュータで走る自己修正的機械語プログラム」
のように眉唾物の長所に思えるかもしれない．
しかし実行時に新しい関数を生成することは，
Lispプログラミングの定石テクニックということが分かるだろう．
%}}}
\subsection{関数の定義} %{{{
大抵，最初に\verb@defun@で関数を定義する方法を習う筈だ．
次の式は引数の2倍を返す\verb@double@という関数を定義する．
\begin{verbatim}
> (defun double (x) (* x 2))
DOUBLE
\end{verbatim}
Lispにこれを与えれば，\verb@double@は他の関数内でも，
トップレベルでも呼び出せる：
\begin{verbatim}
> (double 1)
2
\end{verbatim}
Lispコードのファイルは主にそういった\verb@defun@から成り立っていて，
CやPascalのようなプログラミング言語での手続き定義のファイルに似ている．
しかし大きな違いが明らかになる．
この\verb@defun@は手続き定義ではなく，Lispの呼び出しなのだ．
この区別は\verb@defun@の背後で何が起きているのかを見れば明らかになるだろう．

関数はそれ自身が全くのオブジェクトだ．
実際に\verb@defun@が果たす機能は関数を作り，
1個目の引数として与えられた名前でそれを保持することだ．
だから\verb@double@を呼び出すのと同様，
その機能を実装する関数を得ることができる．
これには普通 \verb@#'@（シャープ・クォート）オペレータを使う．
このオペレータは名前を実際の関数オブジェクトに対応させるものと理解すればいい．
これを\verb@double@の名前の前に置くことで
上の定義で作られた実際のオブジェクトが得られる：
\begin{verbatim}
> #'double
#<Interpreted-Function C66ACE>
\end{verbatim}
表示された表現はLisp処理系の実装ごとに違うけれど，
Common Lispの関数は基本的オブジェクトで，
数や文字列といった親しみ深いオブジェクトと同じ役割を持っている．
だからこの関数を引数として渡したり，返り値として返したり，
データ構造のなかに保存したり，色々なことができる：
\begin{verbatim}
> (eq #'double (car (list #'double)))
T
\end{verbatim}

関数を作るのには\verb@defun@も要らない．
Lispのオブジェクトのほとんどと同じように，それを文字通りに参照することができる．
整数を参照したいときは，ただ整数そのものを使う．
文字列を表現したいときは，ダブルクォートで囲まれた一連の文字を使う．
関数を表現するには，\emph{$\lambda$式}と呼ばれるものを使う．
$\lambda$式はリストで，3部分から成る：\verb@lambda@シンボル，仮引数のリスト，
0個以上の式から成る本体だ．
次の$\lambda$式は\verb@double@と等価な関数を示している：
\begin{verbatim}
(lambda (x) (* x 2))
\end{verbatim}
これは1個の引数$x$を取り，$2x$を返す関数を規定している．

$\lambda$式は関数名とも考えられる．
\verb@double@が「ミケランジェロ」のような固有名だとすれば，
\verb@(lambda (x) (* x 2))@は
「システィーナ礼拝堂の天井画を描いた男」のような，定義となる説明だ．
シャープクォートを$\lambda$式の前に置くことで対応する関数が得られる：
\begin{verbatim}
> #'(lambda (x) (* x 2))
#<Interpreted-Function C674CE>
\end{verbatim}
この関数は\verb@double@と全く同じ働きを持つが，二つは異なったオブジェクトだ．

関数呼び出しでは関数名が先頭に来て，引数が続く：
\begin{verbatim}
> (double 3)
6
\end{verbatim}
$\lambda$式は関数名でもあるから，関数呼び出しの先頭に来ることもできる：
\begin{verbatim}
> ((lambda (x) (* x 2)) 3)
6
\end{verbatim}
Common Lispでは\verb@double@という関数と\verb@double@という変数を
同時に持つことができる．
\begin{verbatim}
> (setq double 2)
2
> (double double)
4
\end{verbatim}
名前が関数呼び出しの先頭かシャープクォートの次に来ると関数への参照と見なされ，
それ以外では変数名と見なされる．

だから「Common Lispには変数と関数に異なった\emph{名前空間}がある．」と言える．
\verb@foo@という変数と\verb@foo@という関数を両方持つことができ，
それらは別々である必要もない．
この状況はややこしく，コードがかなり格好悪くなってしまうことにつながるが，
これはCommon Lispプログラマが付き合っていかなければならないことだ．

必要に応じ，Common Lispではシンボルをその表現する値に対応させたり，
その表現する関数に対応させる関数が使える．
関数\verb@symbol-value@はシンボルを引数に取り，
対応するスペシャル変数の値を返す：
\begin{verbatim}
> (symbol-value 'double)
2
\end{verbatim}
また\verb@symbol-function@はグローバル関数について同じことをする．
\begin{verbatim}
> (symbol-function 'double)
#<Interpreted-Function C66ACE>
\end{verbatim}
関数は普通のデータ・オブジェクトなので，変数が値として関数を持てることに注意：
\begin{verbatim}
> (setq x #'append)
#<Compiled-Function 46B4BE>
> (eq (symbol-value 'x) (symbol-function 'append))
T
\end{verbatim}
背後では，\verb@defun@はその1個目の引数の\verb@symbol-function@を，
残りの引数で組み立てられる関数に設定しているのだ．
次の2個の式は大体同じことをしている：
\begin{verbatim}
(defun double (x) (* x 2))

(setf (symbol-function 'double)
#'(lambda (x) (* x 2)))
\end{verbatim}
だから\verb@defun@は他のプログラミング言語での手続き定義と同じ役割を持つ．
つまり名前をコードの一部に関連づけることだ．
しかし背後の仕組みまで同じではない．
関数を作るのに\verb@defun@は必要ではなく，
関数は何かのシンボルの値として保存されなくてもいい．
他のプログラミング言語の手続き定義に似た\verb@defun@の背後には，
もっと一般的な仕組みが隠れている：
関数を作ることと，それをある名前に関連づけることは別々の働きだ．
Lispの関数の概念の一般性全体までは必要ないとき，
\verb@defun@はもっと制限の強いプログラミング言語と同じ位単純に関数定義を行う．
%}}}
\subsection{関数を引数にする}   %{{{
関数がデータ・オブジェクトであるということは，
何より関数を他の関数の引数として渡せるということだ．
この可能性はLispにおけるボトムアップ・プログラミングの重要性を
支えるものの一つなのだ．

関数がデータ・オブジェクトとなりうるプログラミング言語では，
オブジェクトはそれを呼び出す方法も何か提供しなければならない．
Lispではその関数は\verb@apply@だ．
一般的に\verb@apply@は2個の引数で呼ばれる：
関数と，そのための引数のリストだ．
以下の4個の式はみな同じ働きをする：
\begin{verbatim}
(+ 1 2)
(apply #'+ '(1 2))
(apply (symbol-function '+) '(1 2))
(apply #'(lambda (x y) (+ x y)) '(1 2))
\end{verbatim}
Common Lispでは\verb@apply@には幾つの引数を渡してもよく，
1番目に渡された関数が適用されるのは，
残りの引数を最後のリストにコンシングすることで得られるリストだ．
だからこの式
\begin{verbatim}
(apply #'+ 1 '(2))
\end{verbatim}
は上記の4個の式と等価だ．
引数をリストとして渡すのが不便だと思ったら\verb@funcall@を使えばいい．
これはその点のみが\verb@apply@と違っている．
この式
\begin{verbatim}
(funcall #'+ 1 2)
\end{verbatim}
も上記の式と同じ働きを持つ．

Common Lispの組み込み関数の多くが関数を引数に取れる．
中でも最もよく使われるものの一つが対応付け(mapping)関数だ．
例えば\verb@mapcar@は2個以上の引数（関数と1個以上のリスト，
その関数の取る引数毎にリストが1個必要）を取り，
その関数をそれぞれのリストの要素に先頭から適用していく．
\begin{verbatim}
> (mapcar #'(lambda (x) (+ x 10))
          '(1 2 3))
(11 12 13)
> (mapcar #'+
          '(1 2 3)
          '(10 100 1000))
(11 102 1003)
\end{verbatim}
Lispプログラマにはリストの要素それぞれに対して何か操作を行い，
結果のリストを返してほしいと思うことがよくある．
上の例の1番目はそれを行う古典的な例を示している：
してほしい操作を行う関数を作り，リストに渡って\verb@mapcar@を使う．

関数をデータとして扱えることがどれ程便利なことかは既に見てきた．
多くのプログラミング言語では，
\verb@mapcar@のようなものに関数を引数として渡せるようになっていたとしても，
それはソースファイルのどこかで予め定義された関数でなければならない．
ただコードの一部でリストの要素それぞれに10を加えたいときでも，
\verb@plus_ten@とかいう名の関数をそのためだけに定義しなければならないだろう．
$\lambda$式を使えば関数そのものを直接参照できる．

Common Lispとそれ以前の方言との大きな違いの一つは，
関数を引数に取れる関数が多数組み込まれていることだ．
あらゆるところで目にする\verb@mapcar@の次に多く使われるのは，
\verb@sort@と\verb@remove-if@だ．
前者は多目的の整列関数で，リストと述語を取り，
要素のペアをその述語に渡して整列したリストを返す．
\begin{verbatim}
> (sort '(1 4 2 5 6 7 3) #'<)
(1 2 3 4 5 6 7)
\end{verbatim}
\verb@sort@の動作を覚えるには，重複のないリストを \verb@<@ で整列させ，
その結果に \verb@<@ を適用したら真が返る，と覚えておけばよい．

さてもし\verb@remove-if@がCommon Lispに含まれていなかったら，
これは一番最初に書き加えたいユーティリティだろう．
これは関数とリストを取り，そのリストの要素のうち関数が偽を返すものを全て返す．
\begin{verbatim}
> (remove-if #'evenp '(1 2 3 4 5 6 7))
(1 3 5 7)
\end{verbatim}

関数を引数に取る関数の例として，
ここに\verb@remove-if@の機能限定版の定義を示す：
\begin{verbatim}
(defun our-remove-if (fn lst)
  (if (null lst)
      nil
      (if (funcall fn (car lst))
          (our-remove-if fn (cdr lst))
          (cons (car lst) (our-remove-if fn (cdr lst))))))
\end{verbatim}
この定義の中で\verb@fn@にシャープクォートが付いていないことに注意．
関数はデータ・オブジェクトなので，変数は関数を値として普通に保持することができる．
上でやっていることはそれだ．
シャープクォートはシンボルで表される関数（普通\verb@defun@等で
グローバルに定義されたもの）を参照するときだけしか使わない．

第4章で見るように，関数を引数に取るユーティリティを新しく書くのは
ボトムアップ・プログラミングの重要な要素だ．
Common Lispにはユーティリティがたくさん組み込まれているので，
必要だと思ったものは既に存在しているかもしれない．
しかし\verb@sort@等の組み込みユーティリティを使うにせよ，
自分で書き加えるにせよ，原則に違いはない．
関数を連結せずに，関数を引数に渡せばいい訳だ．
%}}}
\subsection{属性としての関数}   %{{{
関数がLispオブジェクトであるせいで，
新しい事態に対処できるように実行中に拡張できるようなプログラムが書ける．
動物の種類を取り，適切に振る舞う関数が書きたいとしよう．
大抵のプログラミング言語では，これを実現する方法は\verb@case@文だろう．
Lispでも次のようにして実現できる：
\begin{verbatim}
(defun behave (animal)
  (case animal
    (dog (wag-tail)
      (bark))
    (rat (scurry)
      (squeak))
    (cat (rub-legs)
      (scratch-carpet))))
\end{verbatim}
新しい動物を追加したいときにはどうしようか？
新しい動物の追加を計画しているなら，
動物の振る舞いを以下のように定義する方がいいだろう：
\begin{verbatim}
(defun behave (animal)
  (funcall (get animal 'behavior)))
\end{verbatim}
そして個々の動物の振る舞いは，
例えばその名前の属性リストに保存された関数として定義する：
\begin{verbatim}
(setf (get 'dog 'behavior)
  #'(lambda ()
      (wag-tail)
        (bark)))
\end{verbatim}
この方法では，新しい動物を追加するには新しい属性を定義しさえすればいい．
関数の書き直しは必要なくなる．

2番目の方法は柔軟だが，動作が遅いように思われる．事実その通りだ．
もし速度が最重要だというのなら属性リストの代わりに構造体を使い，
また特に関数をコンパイルしておくだろう．
（この方法は第foo章で説明する．）
構造体とコンパイル済み関数を使えば，
柔軟なコードでも\verb@case@文を使った方と同等かそれを凌ぐ速度が出る．

関数のこのような使い方はオブジェクト指向プログラミングでのメソッドの概念に対応する．
一般的に言って，メソッドとはオブジェクトのプロパティである関数であり，
それは正にここで実現したものだ．
このモデルに継承を加えればオブジェクト指向プログラミングの要素がみな揃う．
第foo章で見るように，これは驚く程短いコードで実現できる．

オブジェクト指向プログラミングの最大のセールス・ポイントの一つは，
それによってプログラムが拡張可能になることだ．
この見込みはLispの世界ではそれ程興奮を誘うものではない．
ここでは拡張性はいつも当然のものと見なされているからだ．
必要な種類の拡張性が余り継承に頼らずに済むものなら，素のLispでも十分だろう．
%}}}
\subsection{スコープ}   %{{{
Common Lispはレキシカルスコープを持つLispだ．
Schemeはレキシカルスコープを持つLisp方言のうち最も古いもので，
Scheme以前にはダイナミックスコープはLispの特徴的な機能とされていた．
レキシカルスコープとダイナミックスコープとの違いは，
処理系の実装がどのようにフリー変数を扱うかという点だ．
仮引数として現れるか，
変数を束縛する機能を持つ\verb@let@や\verb@do@等のオペレータによるかして，
変数として作られたシンボルは，式に束縛されている．
束縛されていないシンボルはフリーであると言われる．
次の例では，スコープが動作に絡んでくる：
\begin{verbatim}
(let ((y 7))
  (defun scope-test (x)
    (list x y)))
\end{verbatim}
この\verb@defun@式の中では，\verb@x@が束縛されていて\verb@y@はフリーだ．
フリー変数は，あるべき値が明らかでないので興味深い．
束縛変数の値に関しては曖昧なことは何もない\wadash
\verb@scope-test@が呼ばれたとき，\verb@x@の値はとにかく引数で渡されたものになる．
しかし\verb@y@の値はどうあるべきだろう？
この問の答えはそのLisp方言のスコープの扱いによる．

ダイナミックスコープを持つLispでは，
\verb@scope-test@の実行時のフリー変数の値を見つけるには，
それを呼び出した関数の連鎖を遡る必要がある．
そして\verb@y@が束縛されている環境が見つかれば，
その束縛が\verb@scope-test@で使われているものだ．
見つからなかったら，\verb@y@のグローバルな値が使われる．
だからダイナミックスコープを持つLispでは，
\verb@y@の値は呼び出し側の式の中での値になる：
\begin{verbatim}
> (let ((y 5))
    (scope-test 3))
      (3 5)
\end{verbatim}
ダイナミックスコープでは，\verb@scope-test@が定義された時点で
\verb@y@が7に束縛されていたことには何の意味もない．
影響があるのは，\verb@scope-test@が呼ばれたときに
\verb@y@の値が5だったということだ．

レキシカルスコープを持つLispでは，関数呼び出しの連鎖を遡る代わりに，
関数が定義された時点での周りの環境を遡って調べる．
レキシカルスコープを持つLispでは，上の例の\verb@y@は
\verb@scope-test@が定義された時点での束縛を持つだろう．
またCommon Lispでもそうなる：
\begin{verbatim}
> (let ((y 5))
    (scope-test 3))
      (3 7)
\end{verbatim}
ここで，呼び出し時に\verb@y@を5に束縛したことは返り値に何の影響も持たない．

変数をスペシャル宣言することでダイナミックスコープを持たせることができるが，
Common Lispでは普通はレキシカルスコープになる．
一般的に言って，Lispコミュニティはダイナミックスコープの廃止を
ほとんど残念に思っていないようだ．
一つには，それが恐ろしく捉えづらいバグを招いたことがある．
しかしレキシカルスコープはバグ回避の方法程度のものではない．
次章で見るように，それによって幾つかの新しいプログラミング技法が可能になる．
%}}}
\subsection{クロージャ} %{{{
Common Lispがレキシカルスコープを持つせいで，
フリー変数を中に含む関数を定義したときには，
処理系はその関数が定義された時点でのそれらの変数の束縛をコピーして保存しなければならない．
関数と変数束縛の一式のそのような組み合わせは\emph{クロージャ}と呼ばれる．
クロージャは多方面の応用において便利なものだと分かるだろう．

クロージャはCommon Lispの中に広く浸透しているので，
それとは意識することさえなく使うことができる．
\verb@mapcar@にフリー変数を含む$\lambda$式をシャープクォートして与える度，
ユーザはクロージャを使っているのだ．
例えば，数のリストを取り，ある数をそれぞれに加える関数を書きたいとしよう．
この関数\verb@list+@
\begin{verbatim}
(defun list+ (lst n)
  (mapcar #'(lambda (x) (+ x n))
          lst))
\end{verbatim}
が望みの動作をしてくれる：
\begin{verbatim}
> (list+ '(1 2 3) 10)
(11 12 13)
\end{verbatim}
\verb@list+@ の中で\verb@mapcar@に渡される関数をよく見れば，
それが実際クロージャだと分かる．
\verb@n@のインスタンスはフリーで，その束縛は周りの環境から来ている．
レキシカルスコープの下では，
そのような対応付け関数を使う度にクロージャが作られている
\footnote{ダイナミックスコープの下でも，
\texttt{mapcar}の仮引数がどれも\texttt{x}という名を持たない限り同じ例文が機能するが，
その理由は異なる．}．

AbelsonとSussmanの古典\emph{Structure and Interpretation of Computer
Programs}\note{WizardBook}によって奨められたプログラミング・スタイルでは，
クロージャはさらに顕著な役を担っている．
クロージャはローカルな状態を持った関数であるとされる．
この状態を使う例の最も単純なものは次のような状況だ：
\begin{verbatim}
(let ((counter 0))
  (defun new-id () (incf counter))
  (defun reset-id () (setq counter 0)))
\end{verbatim}
これら2個の関数はカウンタとして働く変数を共有している．
1個目はカウンタを1増やしてその値を返し，2個目はカウンタを0にリセットする．
カウンタをグローバル変数とすることで同じことが実現できるが，
この方法ではカウンタは意図しない参照から守られている．
ローカルな状態を持つ関数を返せるのは便利でもある．
例えば，関数\verb@make-adder@
\begin{verbatim}
(defun make-adder (n)
  #'(lambda (x) (+ x n)))
\end{verbatim}
は数を取り，「呼ばれると引数にその数を加えるクロージャ」を返す．
その足し算関数のインスタンスは幾らでも作ることができる：
\begin{verbatim}
> (setq add2 (make-adder 2)
        add10 (make-adder 10))
#<Interpreted-Function BF162E>
> (funcall add2 5)
7
> (funcall add10 3)
13
\end{verbatim}
\verb@make-adder@に返されたクロージャでは内部状態が固定されているが，
状態を変化させられるクロージャを作ることもできる．
\begin{verbatim}
(defun make-adderb (n)
  #'(lambda (x &optional change)
      (if change
          (setq n x)
          (+ x n))))
\end{verbatim}
上の新ヴァージョンの\verb@make-adder@が返すクロージャは，
1個の引数で呼ばれたときには古いものと全く同じ動作をする：
\begin{verbatim}
> (setq addx (make-adderb 1))
#<Interpreted-Function BF1C66>
> (funcall addx 3)
4
\end{verbatim}
しかし新しい足し算関数が非nilの第2引数と共に呼ばれると，
内部にある\verb@n@のコピーは第1引数として渡された値にリセットされる：
\begin{verbatim}
> (funcall addx 100 t)
100
> (funcall addx 3)
103
\end{verbatim}
同じデータ・オブジェクトを共有するクロージャのグループを返すことさえ可能だ．
第\ref{fig:PrimitivDatebase}図には初歩的データベースを作る関数を示した．
それは連想リスト(\verb@db@)を取り，それぞれエントリのクエリ，追加，削除を行う
3個のクロージャのリストを返す．
\verb@make-dbms@を呼び出す度，
連想リストの自分専用のコピーを内部で共有する新しい関数の組が返される．
\begin{verbatim}
> (setq cities (make-dbms '((boston . us) (paris . france))))
(#<Interpreted-Function 8022E7>
 #<Interpreted-Function 802317>
 #<Interpreted-Function 802347>)
\end{verbatim}

\begin{figure}\begin{center}\begin{FramedVerb}
(defun make-dbms (db)
  (list
    #'(lambda (key)
        (cdr (assoc key db)))
    #'(lambda (key val)
        (push (cons key val) db)
        key)
    #'(lambda (key)
        (setf db (delete key db :key #'car))
        key)))
\end{FramedVerb}\end{center}
\caption{3個のクロージャがリストを共有する例．}
\label{fig:PrimitivDatebase}
\end{figure}

データベース内の実際の連想リストは，外からは見えない．
それどころか，それが連想リストなのかどうかも分からない．
しかしそれは\verb@cities@のコンポーネントである関数を通じて到達できる：
\begin{verbatim}
> (funcall (car cities) 'boston)
US
> (funcall (second cities) 'london 'england)
LONDON
> (funcall (car cities) 'london)
ENGLAND
\end{verbatim}
リストの\verb@car@を呼ぶのは少し格好悪い．
実際のプログラムでは，アクセス関数は構造体のエントリでもいいかもしれない．
それらを使うとさらに簡潔になるだろう．
データベースは次のような関数
\begin{verbatim}
(defun lookup (key db)
  (funcall (car db) key))
\end{verbatim}
から間接的にアクセスできるようになる．
しかし，クロージャの基本的な動作はそういったチューニングとは無関係だ．
実際のプログラム使われるクロージャとデータ構造は，
\verb@make-adder@や\verb@make-dbms@で見たものより手の込んだものだろう．
共有されている変数は1個だったが，幾つに増やしてもよく，
それぞれはどのようなデータ構造にも束縛できる．
クロージャはLispの長所のうち顕著で明白なものの一つだ．
Lispプログラムの中には，
努力すれば力の弱いプログラミング言語に翻訳できるものもあるかもしれない．
しかし上のようなクロージャを使うプログラムを翻訳しようとしてみれば，
この抽象化構造がどれ程労力の節約になっているか明らかになるだろう．
後の章ではクロージャをさらに詳細に扱う．
第5章では，それらを使って複合的な関数を作る方法を示す．
第6章では，伝統的データ構造の代わりとしての使用法を見る．
%}}}
\subsection{ローカル関数}   %{{{
$\lambda$式で関数を定義したとき，\verb@defun@では分からなかった制限に直面する：
$\lambda$式で定義した関数には名前がなく，そのためにそれ自身を参照する方法がない．
このことは，Common Lispでは再帰関数を定義するのに$\lambda$式が使えないということだ．
ある関数をリストの要素全てに適用したいときは，
Lispの慣用法のうち最も親しみ深いものを使う：
\begin{verbatim}
> (mapcar #'(lambda (x) (+ 2 x))
          '(2 5 7 3))
(4 7 9 5)
\end{verbatim}
\verb@mapcar@の第1引数に再帰関数を与えたいときにはどうすればいいのだろうか？
その関数が\verb@defun@で定義されていたら，
ただ関数の名前によってそれを参照すればいい：
\begin{verbatim}
> (mapcar #'copy-tree '((a b) (c d e)))
((A B) (C D E))
\end{verbatim}
しかし使う関数が，\verb@mapcar@の存在する環境から
幾つかの束縛を引き継ぐようなクロージャでなくてはいけないとしよう．
例に挙げた\verb@list+@
\begin{verbatim}
(defun list+ (lst n)
  (mapcar #'(lambda (x) (+ x n))
          lst))
\end{verbatim}
では\verb@mapcar@への第1引数 \verb@#'(lambda (x) (+ x n))@は
\verb@list+@ 内で定義されていなければいけない．
それは\verb@n@の束縛を捉えなければいけないからだ．
そこまではいいが，ローカルな束縛を必要とし，
かつ再帰的な関数を\verb@mapcar@に与えたいとしたらどうだろう？
ローカルな束縛が必要だから，別の場所で\verb@defun@で定義された関数は使えない．
また$\lambda$式で再帰関数を定義することはできない．
その関数には自分自身を参照する方法がないからだ．
このジレンマを解決するため，Common Lispには\verb@labels@が用意されている．
1点の重要な留保を除き，\verb@labels@は関数に対する一種の\verb@let@として説明できる．
\verb@labels@式の中の束縛指定部は，それぞれ次のような形になる：\\[1.5ex]
\verb@(@$\langle$名前$\rangle~\langle$仮引数$\rangle$
\verb@.@ $\langle$本体$\rangle$\verb@)@\\[1.5ex]
\verb@labels@式の中では，
\verb@name@は次のような関数と等価な関数を参照する：\\[1.5ex]
\verb@(lambda@ $\langle$仮引数$\rangle$ \verb@.@ $\langle$本体$\rangle$\verb@)@\\[1.5ex]
例を挙げよう：
\begin{verbatim}
> (labels ((inc (x) (1+ x)))
          (inc 3))
4
\end{verbatim}
しかし\verb@let@と\verb@labels@には重要な違いがある．
\verb@let@式の中では，
ある変数の値は同じ\verb@let@で作られた別の変数に依存することはできない．つまり
\begin{verbatim}
(let ((x 10) (y x))    ;;誤り
  y)
\end{verbatim}
として，新しい\verb@y@の値が新しい\verb@x@の値を反映することを期待しても駄目なのだ．
それに対し，\verb@labels@式の中で定義された関数\verb@f@の本体では，
そこで定義されたどの関数を参照してもいい．
それは\verb@f@自身でもよく，おかげで再帰関数の定義が可能になっている．
\verb@labels@を使って\verb@list+@ に似た関数を書けるが，
こちらでは\verb@mapcar@への第1引数が再帰関数になっている：
\begin{verbatim}
(defun count-instances (obj lsts)
  (labels ((instances-in (lst)
             (if (consp lst)
                 (+ (if (eq (car lst) obj) 1 0)
                    (instances-in (cdr lst)))
                 0)))
    (mapcar #'instances-in lsts)))
\end{verbatim}
この関数は1個のオブジェクトと1個のリストを取り，
そのリストの要素内にオブジェクトが何個あったかの回数のリストを返す：
\begin{verbatim}
> (count-instances 'a '((a b c) (d a r p a) (d a r) (a a)))
(1 2 1 2)
\end{verbatim}
%}}}
\subsection{末尾再帰}   %{{{
再帰関数とは自分自身を呼び出す関数だ．
そして関数呼び出しの後に行うべき作業が残っていなければ，
その呼び出しは\emph{末尾再帰}だ．
次の関数は末尾再帰でない．
\begin{verbatim}
(defun our-length (lst)
  (if (null lst)
      0
      (1+ (our-length (cdr lst)))))
\end{verbatim}
再帰呼び出しから戻った後，結果を\verb@1+@ に渡さなければいけないからだ．
しかし次の関数は末尾再帰だ．
\begin{verbatim}
(defun our-find-if (fn lst)
  (if (funcall fn (car lst))
      (car lst)
      (our-find-if fn (cdr lst))))
\end{verbatim}
再帰呼び出しの値が即座に返されているからだ．
多くのCommon Lispコンパイラが末尾再帰の関数をループに変換できるので，
末尾再帰の方がいい．
そのようなコンパイラでは，
優美な再帰をソースコード内で使っても実行時に関数呼び出しのオーヴァヘッドは必要ない．
末尾再帰にすると速度は大抵かなり向上するので，
Lispプログラマはどんどん関数を末尾再帰にしようとする．
末尾再帰でない関数もしばしば末尾再帰に変換できることがある．
それには総和変数を使うローカルな関数を埋め込んでやればいい．
ここで総和変数とはそれまでに計算された値を保持するパラメータを指す．
例えば\verb@our-length@は次のように変換できる：
\begin{verbatim}
(defun our-length (lst)
  (labels ((rec (lst acc)
           (if (null lst)
               acc
               (rec (cdr lst) (1+ acc)))))
    (rec lst 0)))
\end{verbatim}
ここでそれまでに読み取ったリストの要素の数は，
第2仮引数\verb@acc@に保持されている．
再帰がリスト末尾まで達したとき\verb@acc@の値がリスト全体の長さになっているので，
それをそのまま返せばいい．
呼び出しのツリーから戻る途中で値を求めていくのでなく，
呼び出しのツリーを下るにつれ値を累積していくことで，
\verb@rec@を末尾再帰に変えることができる．

Common Lispコンパイラの多くが末尾再帰の最適化を行うことができるが，
それら全てが始めからそうする設定になっている訳ではない．
だから自分の関数を末尾再帰に書き換えたら，ファイルの先頭に
\begin{verbatim}
(proclaim '(optimize speed))
\end{verbatim}
と付け足し，努力の成果をコンパイラが確かに活用できるようにするといいかもしれない
\footnote{宣言\texttt{(optimize speed)}は\texttt{(optimize (speed 3))}の
省略形の筈だが，あるCommon Lisp処理系は前者では末尾再帰の最適化をするのに，
後者ではしないことが分かっている．}．

末尾再帰形式と型宣言を与えられると，
現在のCommon LispコンパイラはCと同等か，Cより速いコードを生成できる．
Richard Gabriel\note{Gabriel}による下の例の関数は，
\verb@1@から\verb@n@までの整数の和を返す：
\begin{verbatim}
(defun triangle (n)
  (labels ((tri (c n)
                (declare (type fixnum n c))
                (if (zerop n)
                    c
                    (tri (the fixnum (+ n c))
                         (the fixnum (- n 1))))))
    (tri 0 n)))
\end{verbatim}
高速なCommon Lispコードはこういう形になる．
始めは関数をこのように書くのは不自然に思えるかもしれない．
始めは関数をとにかく一番自然に思える形で書き，
その後必要があれば等価な末尾再帰形式に書き換えるのがいい．
%}}}
\subsection{コンパイル} %{{{
Lispの関数は1個1個でもファイル単位でもコンパイルできる．
トップレベルに\verb@defun@式を打ち込むだけだと
\begin{verbatim}
> (defun foo (x) (1+ x))
FOO
\end{verbatim}
多くの処理系が作るのは（コンパイルされていない）インタプリタに読み込まれた関数だ．
ある関数がコンパイルされているかどうかは，
それを\verb@compiled-function-p@に渡せば分かる：
\begin{verbatim}
> (compiled-function-p #'foo)
NIL
\end{verbatim}
\verb@foo@をコンパイルするにはその名前を\verb@compile@に与える：
\begin{verbatim}
> (compile 'foo)
FOO
\end{verbatim}
これは\verb@foo@の定義をコンパイルし，
評価された関数をコンパイル済みのものに置き換える関数だ\note{compile}．
\begin{verbatim}
> (compiled-function-p #'foo)
T
\end{verbatim}
コンパイル済みの関数と評価された関数は共にLispのオブジェクトで，
違うのは\verb@compiled-function-p@を適用したときの結果だけだ．
関数を文字通りに表記したものもコンパイルできる：
\verb@compile@は第1引数がコンパイルする関数の名前であることを期待するが，
第1引数に\verb@nil@を与えると，第2引数で与えられた$\lambda$式をコンパイルする．
\begin{verbatim}
> (compile nil '(lambda (x) (+ x 2)))
#<Compiled-Function BF55BE>
\end{verbatim}
名前と関数を両方与えると，\verb@compile@は
\verb@defun@をコンパイルするような形になる：
\begin{verbatim}
> (progn (compile 'bar '(lambda (x) (* x 3)))
(compiled-function-p #'bar))
T
\end{verbatim}
プログラミング言語の中にコンパイルの命令があるということは，
プログラムが実行中に新しい関数を作ってコンパイルできるということだ．
しかし\verb@compile@を陽に呼ぶのは，
\verb@eval@を呼ぶのに匹敵する程過激な方法で，同じくらい疑ってかかるべきだ
\footnote{陽に\texttt{eval}を呼ぶのがなぜいけないかは，fooページで説明する．}．
第2.1節で実行時に関数を作るのは頻繁に使われるプログラミング技法だと言ったが，
それは\verb@make-adder@に作られた新しいクロージャ等を指しており，
生のリストに対して\verb@compile@を呼んで作った関数のことではない．
\verb@compile@を呼ぶのは頻繁に使われる技法ではない\wadash その方法は物凄く希だ．
だから不必要に使うのは避けること．
Lispの上に別のプログラミング言語を実装するのでもない限り
（そしてその場合でさえ大抵は），必要なことはマクロを使えば可能だろう．

2種類の関数は\verb@compile@に引数として与えることができない．
\textsf{CLtL2}によると（voxページ），
「空でないレキシカル環境においてインタプリタ的に定義された関数」だ．
つまりトップレベルで\verb@let@を使って\verb@foo@を定義すると
\begin{verbatim}
> (let ((y 2))
(defun foo (x) (+ x y)))
\end{verbatim}
\verb@(compile 'foo)@には意味がない
\footnote{このコードをファイルに保存し，ファイルをコンパイルするのは問題ない．
制限は実装上の理由から「インタプリタ的に読み込まれたコード」という点に
対するもので，異なるレキシカル環境で関数を定義することに何も問題はない．}．
また既にコンパイル済みの関数で\verb@compile@を呼ぶこともできない．
この状況に関し\textsf{CLtL2}は不吉な示唆をしている．
曰く，「そのときの結果は…不定である．」

Lispコードをコンパイルする方法は，普通，
関数を個別に\verb@compile@でコンパイルするのでなく，
ファイル全体を\verb@compile-file@でコンパイルすることだ．
この関数はファイル名を取り，ソースファイルのコンパイル済みのものを造り出す．
ファイル名本体は同じで拡張子が違う，というのが典型的なものだ．
コンパイル済みファイルが読み込まれると，
\verb@compiled-function-p@はそのファイルで定義された全ての関数に真を返す筈だ．
後の章では，コンパイルの別の効果を使っている：
ある関数が別の関数内で作られ，外側の関数がコンパイルされると，
内側の関数もコンパイルされる．
\textsf{CLtL2}ではこうなるとは明記していないようだが，
ちゃんとした処理系ではこうなる筈と考えていい．

内部の関数のコンパイルの問題は，関数を返す関数を使うと明らかになる．
\verb@make-adder@（fooページ）がコンパイルされると，
それが返す関数もコンパイルされている：
\begin{verbatim}
> (compile 'make-adder)
MAKE-ADDER
> (compiled-function-p (make-adder 2))
T
\end{verbatim}
後の章で見るように，この事実は埋め込み言語の実装において大変重要だ．
新しいプログラミング言語がコード変換によって実装されているとき，
変換を司るコードがコンパイルされると，それはコンパイル済みコードを生成する．
そして新しいプログラミング言語のためのコンパイラでその問題が明らかになる．
（簡単な例をbazページで説明した．）

かなり小さい関数を定義したときは，それをインラインでコンパイルしてほしいことがある．
そうしないと呼び出し機構に関数自体よりも多くの手間がかかってしまう．
関数を定義して
\begin{verbatim}
(defun 50th (lst) (nth 49 lst))
\end{verbatim}
インライン宣言をすると
\begin{verbatim}
(proclaim '(inline 50th))
\end{verbatim}
コンパイル済み関数内での\verb@50th@への参照には実際の関数呼び出しが要らなくなる．
このとき\verb@50th@を呼び出す関数を定義してコンパイルすると
\begin{verbatim}
(defun foo (lst)
  (+ (50th lst) 1))
\end{verbatim}
\verb@50th@のコードはその中にそのまま組み入れられる．
すると最初の所で次のように書いたかのような結果になる：
\begin{verbatim}
(defun foo (lst)
  (+ (nth 49 lst) 1))
\end{verbatim}
インライン関数の欠点は，
\verb@50th@を定義し直したときには\verb@foo@を再コンパイルしなくてはいけないことだ．
そうしないと\verb@foo@は\verb@50th@の古い定義を反映したままになってしまう．
インライン関数に対する制限は，マクロに対するものと基本的に同じだ
（第foo章を参照）\note{inline}．
%}}}
\subsection{リストから作られる関数} %{{{
Lispの初期の方言では，関数がリストとして表現されているものがあった．
このことはLispプログラムに自分自身でLispプログラムを書き，実行するという
注目すべき能力をもたらした．
Common Lispでは，関数はもうリストから作られてはいない\wadash
よくできた処理系は関数をネイティブな機械語にコンパイルする．
しかしプログラムを書くプログラムをユーザが書くことは依然として可能だ．
それはリストがコンパイラに対する入力形式だからだ．

LispプログラムがLispプログラムを書けるということは，
どんなに強調しても強調し過ぎにはならない．
特に，この事実はしばしば軽く見られがちだからだ．
熟練Lispユーザでさえ，Lispのこの機能から得られる利点を理解していることは少ない．
例えばLispのマクロがあれ程強力な理由はこれだ．
この本で説明されている技法のほとんどが，
Lispの式を操作できるプログラムを書ける能力によるものだ．
%}}}
%}}}
\section{関数的プログラミング}  %{{{
前の章では，LispとLispのプログラムが共に一つの材料から成り立っている様子を説明した．
どの建材でも同様だが，材料の性質は建物の性質とそれを建てる方法に影響を与える．

この章では，Lispの世界で広く使われている建築技法の種類を説明する．
これらの方法に精通すれば，もっと思い切った種類のプログラムを書こうという気になる．
次の章では，Lispで可能になる，特に重要な種類のプログラムを説明する：
古い「計画－実装」方式で開発されるのでなく，進化していくプログラムだ．
\subsection{関数的デザイン} %{{{
オブジェクトの性格はそれを作る要素に影響を受ける．
例えば木造の建物は石造りの建物とは違った見掛けになる．
木や石そのものを見る機会が全くない人でも，
建物の全体的な形からそれが何でできているかは分かるだろう．
Lispの関数の性格はLispのプログラムの構造に対して似たような影響を及ぼしている．

関数的プログラミングとは，副作用ではなく，
値を返すことで動作するプログラムを書くことだ．
副作用とはオブジェクトの破壊的な変更（\verb@rplaca@の使用等）や
変数への代入（\verb@setq@の使用等）を含む．
副作用を使う数が少なく，その影響範囲もローカルなものであれば，
プログラムの読み取り，テスト，デバッグは簡単になる．
Lispのプログラムが必ずこの方法で書かれてきた訳ではないが，
時を追ってLispと関数的プログラミングは次第に分かち難いものになってきた．

関数的プログラミングが別のプログラミング言語でのプログラミングと
どれ程違うのかは，例を見れば分かるだろう．
何かの理由であるリストが逆順になったものの要素が欲しいとしよう．
そのときリストを逆順にする関数を書くのではなく，
リストを引数とし，同じ要素で逆順のリストを返す関数を書く．

\begin{figure}\begin{center}\begin{FramedVerb}
(defun bad-reverse (lst)
  (let* ((len (length lst))
         (ilimit (truncate (/ len 2))))
    (do ((i 0 (1+ i))
         (j (1- len) (1- j)))
        ((>= i ilimit))
      (rotatef (nth i lst) (nth j lst)))))
\end{FramedVerb}\end{center}
\caption{リストの要素の順を逆転させる関数．}
\label{fig:ReversingList}
\end{figure}

第\ref{fig:ReversingList}図はリストを逆順にする関数だ．
これはリストを配列として扱い，要素の場所を使って逆転させる．
返り値に意味はない：
\begin{verbatim}
> (setq lst '(a b c))
(A B C)
> (bad-reverse lst)
NIL
> lst
(C B A)
\end{verbatim}
名前が示すように，\verb@bad-reverse@はLispでのよいスタイルとは程遠い．
それどころか伝染病のような醜さを持っている：
つまりこれが副作用によって働き，
また呼び出し側に対しても関数的プログラミングの理想を妨げるということだ．
悪者役にされてしまったが\verb@bad-reverse@には長所が1個ある．
これは2個の値を入れ替えるときのCommon Lispでの慣用法を示している．
\verb@rotatef@マクロは任意の数の汎変数（generalized variable，
\verb@setf@の第1引数として与えることができる式）の値を逆に並び替える．
そして引数が2個だけの時にはそれらを交換する．
対照的に，第\ref{fig:ReversingList}図は逆順のリストを返す関数を示している．
\verb@good-reverse@では返り値として逆順のリストが得られ，元のリストはそのままだ．
\begin{verbatim}
> (setq lst '(a b c))
(A B C)
> (good-reverse lst)
(C B A)
> lst
(A B C)
\end{verbatim}

かつては人の容貌を見ればその人の性格が分かると思われていた．
これが人間に対して正しかろうとそうでなかろうと，
Lispプログラムに対しては一般的に正しい．
関数的プログラムは命令的プログラムと異なった容貌を持っている．
関数的プログラムの構造は全て式内部の引数の構成によって決まり，
また引数がインデントされているので，そのインデント方法は多岐に渡る．
関数的プログラムのコードはページ内を流れていくように見える
\footnote{特徴的な例についてはbumpページを参照．}．
命令的プログラムのコードは固定的でブロックに別れていて，ちょうどBasicに似ている．

\begin{figure}\begin{center}\begin{FramedVerb}
(defun good-reverse (lst)
  (labels ((rev (lst acc)
           (if (null lst)
               acc
               (rev (cdr lst) (cons (car lst) acc)))))
    (rev lst nil)))
\end{FramedVerb}\end{center}
\caption{要素の順が逆転したリストを返す関数．}
\label{fig:ReversedList}
\end{figure}

眺めるだけでも，\verb@bad-reverse@と\verb@good-reverse@の
どちらがいいかが伝わってくる．
そして短いだけでなく\verb@good-reverse@は効率的でもある：
$O(n^2)$ではなく$O(n)$なのだ．

Common Lispには組み込みで\verb@reverse@があるので，それを書く手間は要らない．
この関数はしばしば関数的プログラミングに対する表面的な誤解をもたらすので，
軽く見ておく価値はある．
\verb@good-reverse@と同様，組み込みの\verb@reverse@も値を返すことで働く\wadash
その引数は手付かずだ．
しかしLispの学習途中の人は，
それが\verb@bad-reverse@のように副作用によって働いていると思うかもしれない．
プログラムのどこかでリスト\verb@lst@を逆順に変えたいとき
\begin{verbatim}
(reverse lst)
\end{verbatim}
と書いて，どうして呼び出しの効果が出ないのだろう，と思うかもしれない．
実際は，そういった関数の副作用が欲しいときには呼び出しコードの中で
副作用が起きるようにしてやらなければいけない．
つまり，代わりに
\begin{verbatim}
(setq lst (reverse lst))
\end{verbatim}
と書く必要があるということだ．
\verb@reverse@等のオペレータは，副作用でなく返り値のために呼ばれるよう意図されている．
自分のプログラムもこのスタイルで書く価値がある\wadash
Lispの生まれ持った長所のためばかりでなく，
そうしないとLispに逆らってプログラムを書くことになるからだ．

\verb@bad-reverse@と\verb@good-reverse@との比較で無視していた点の一つは，
\verb@bad-reverse@はコンシングをしない点だ．
新しい構造を作るのでなく，元のリストに対して動作している．
これは危険となりうる\wadash
そのリストはプログラムのどこかで必要になっているかもしれない．
しかし効率のためにはそれが必要なときもある．
そんな場合のために，Common Lispには$O(n)$オーダーの破壊的な逆転関数
\verb@nreverse@がある\note{nreverse}．

破壊的関数とは渡された引数に変更を及ぼせる関数だ．
しかし破壊的関数さえも普通は返り値のために使われる：
\verb@nreverse@は引数として与えられたリストを使い回すと思わなければいけないが，
それがリストを逆順に変えてくれると思ってはいけない．
これまでのものと同様，逆順になったリストは返り値によって得られる．
関数の途中に
\begin{verbatim}
(nreverse lst)
\end{verbatim}
と書いても，それ以後\verb@lst@が逆順になっていると思ってはいけない．
大抵の処理系では次のようなことが起きる：
\begin{verbatim}
> (setq lst '(a b c))
(A B C)
> (nreverse lst)
(C B A)
> lst
(A)
\end{verbatim}
\verb@lst@を逆順に変えるためには，
普通の\verb@reverse@でやるのと同じように\verb@lst@に返り値を代入しなければいけない．

ある関数が破壊的だと書かれていても，
その関数が副作用のために呼ばれる筈の関数だということではない．
危ない点は，幾つかの破壊的関数がそういった印象を与えることだ．
例えば
\begin{verbatim}
(nconc x y)
\end{verbatim}
と
\begin{verbatim}
(setq x (nconc x y))
\end{verbatim}
とはほぼ同じ効果を持つ．
前者の慣用法によるコードを書くと，正しく働くように思えることもあるかもしれない．
しかし\verb@x@がnilのときには思った通りの動作をしないだろう．

Lispオペレータのうち，副作用のために呼ばれるよう意図されているものはほんの僅かだ．
一般的に言って，組み込みオペレータは返り値のために呼ばれるよう意図されている．
\verb@sort@，\verb@remove@や\verb@substitute@等の名前に惑わされてはいけない．
副作用が必要なら，返り値を\verb@setq@で代入すること．

まさにこのルールが，副作用を不可避なものにしている．
関数的プログラミングを理想とするというのは，
プログラムが決して副作用を使ってはいけないということではない．
ただ必要以上に使うべきでないということだ．

この習慣を育てるには時間がかかるかもしれない．
一つの方法は，以下のオペレータは税金がかかっているつもりで扱うことだ：
\begin{verbatim}
set setq setf psetf psetq incf decf push pop pushnew
rplaca rplacd rotatef shiftf remf remprop remhash
\end{verbatim}
あと\verb@let*@もそうだ．
この中に命令的プログラムが潜んでいることがしばしばある．
これらのオペレータに税金がかかっているつもりになるのは，
よいLispのプログラミング・スタイルへ向かう手助けとして勧めただけで，
それがよいスタイルの基準なのではない．
しかし，それだけでもずいぶん進歩できるだろう．

他のプログラミング言語では，副作用を使う理由で最も大きいものは，
多値を返す関数が必要になることだ．
関数が1個の値しか返せなければ，他の値はパラメータに変更を加えることで「返す」しかない．
幸運なことに，Common Lispではその必要はない．
どの関数も多値を返せるからだ．

例えば組み込み関数\verb@truncate@は2個の値
（切り捨て結果の整数と切り捨てられた部分）を返す．
典型的な処理系では，トップレベルで\verb@truncate@を呼ぶと両方を表示する：
\begin{verbatim}
> (truncate 26.21875)
26
0.21875
\end{verbatim}
呼び出し側のコードが値を1個しか取らないときは，1番目が使われる：
\begin{verbatim}
> (= (truncate 26.21875) 26)
T
\end{verbatim}
\verb@multiple-value-bind@を使うことで，
呼び出し側コードは両方の返り値を捉えることができる．
このオペレータは変数のリスト，関数呼び出し，コード本体を引数に取る．
本体が評価されるときには，関数呼び出しからの返り値は各々が変数に代入されている：
\begin{verbatim}
> (multiple-value-bind (int frac) (truncate 26.21875)
    (list int frac))
(26 0.21875)
\end{verbatim}
最後に，多値を返すには\verb@values@オペレータを使う：
\begin{verbatim}
> (defun powers (x)
    (values x (sqrt x) (expt x 2)))
POWERS
> (multiple-value-bind (base root square) (powers 4)
    (list base root square))
(4 2.0 16)
\end{verbatim}

全体的に見て関数的プログラミングはいい方法だ．
それはLispで使うには特にいい．
と言うのもLispは関数的プログラミングを支援するために進化してきたからだ．
\verb@reverse@や\verb@nreverse@等の組み込みオペレータは
このように使われることを意図している．
\verb@values@や\verb@multiple-value-bind@等のオペレータは，
関数的プログラミングを簡単にするために特に用意されたものだ．
%}}}
\subsection{命令的プログラミングの裏返し}   %{{{
関数的プログラミングの狙いは，
もっと普通のアプローチ，命令的プログラミングの狙いと対比させると
はっきり見えてくるかもしれない．
関数的プログラムは，それが欲しがるものを求める．
命令的プログラムは，何をすべきかの指示を求める．
関数的プログラムの
「\verb@a@と，\verb@x@の第1要素の2乗から成るリストを返せ．」：
\begin{verbatim}
(defun fun (x)
  (list 'a (expt (car x) 2)))
\end{verbatim}
命令的プログラミングではこうだ．
「\verb@x@の第1要素を求め，それを2乗せよ．
そして\verb@a@と，先程2乗した値から成るリストを返せ．」：
\begin{verbatim}
(defun imp (x)
  (let (y sqr)
    (setq y (car x))
    (setq sqr (expt y 2))
    (list 'a sqr)))
\end{verbatim}
このプログラムを両方の方法で書けるLispユーザは幸運だ．
命令的プログラミングだけに適したプログラミング言語もある\wadash
Basicと，ほとんどのマシン語だ．
実際，\verb@imp@の定義はほとんどのLispコンパイラが\verb@fun@に対して
生成するマシン語と構成が似ている．

コンパイラが代わりにやってくれるのに，どうしてそんなコードを書くのだろう？
多くのプログラマには，この疑問は浮かびすらしない．
プログラミング言語はそのパターンを私達の考えに焼き付ける：
命令的プログラミングに慣れてしまった人は，
プログラムを命令的プログラミング用語で考えるようになってしまった結果，
実際に関数的プログラミングより命令的プログラミングの方が易しく思えるのかもしれない．
この精神的習慣は，乗り越える価値のあるものだ\wadash
そうさせてくれるプログラミング言語を持っているなら．

他のプログラミング言語の卒業生にとっては，
Lispを使い始めるのは始めてスケートリンクの上に立つのと似ているかもしれない．
氷の上で動き回るのは陸上で動き回るのより実際はずっと簡単だ\wadash
スケート靴を使えば．
そうするまではこのスポーツが何だというのかと一人ぽつんと悩むことになるだろう．

スケートと氷の関係は，関数的プログラミングとLispとの関係と同じだ．
それらを組み合わせれば，優雅に，しかも苦労せずにあちこち回れるようになる．
しかし別の種類の移動方法に慣れてしまっていると，始めは何やら感じが掴めないだろう．
第二言語としてLispを学ぶときにはっきり理解しにくい点の一つは，
関数的プログラミングのスタイルを学ぶことだろう．

幸運なことに，命令的プログラムを関数的プログラムに変換するうまい方法がある．
この方法は完成したコードに適用することから始めるといい．
すぐに勘が働くようになり，コードを書きながら変換できるようになるだろう．
そうすればあっという間に，
始めから関数的プログラミングの用語でプログラムを考えるようになるだろう．

その方法は，命令的プログラムは関数的プログラムを裏返しにしたものと思うことだ．
関数的プログラムが命令的プログラムの中に隠れているのを見つけるには，
ただ裏返しにすればいい．
この方法を\verb@imp@で試してみよう．

最初に気付くのは，先頭の\verb@let@内で\verb@y@と\verb@sqr@を作っていることだ．
これはよくないことが続く前触れだ．
実行時の\verb@eval@の呼び出しと同様，
初期化されていない変数は滅多に使われないので，
一般的に言ってプログラム内で変なことをした現れと見なしていい．
そういった変数はしばしばプログラムを留める画鋲のようなもので，
プログラムが自然な形になろうとするのを妨げている．

しかしここではそれは暫く無視し，関数の終わりまでまっすぐ進んでみる．
命令的プログラムで最後に起きることは，関数的プログラムでは一番最初に起きる．
だから最初の一歩は最後に行われる\verb@list@の呼び出しを掴み，
プログラムの残りをその中に詰め込むことだ\wadash
シャツを裏返しにするように．
そしてシャツを袖からカフスにかけて次第に裏返していくように，
同じ変換方法を繰り返し適用し続けていく．

後ろから見ていって，\verb@sqr@を\verb@(expt y 2)@で置き換え
\begin{verbatim}
(list 'a (expt y 2)))
\end{verbatim}
が得られる．
次に\verb@y@を\verb@(car x)@で置き換えると
\begin{verbatim}
(list 'a (expt (car x) 2))
\end{verbatim}
となる．
こうしてコードの残りは最後の式の中に詰め込まれたので，
それを捨て去ることができるようになった．
ここに至るまでに変数\verb@y@と\verb@sqr@の必要性はなくなったので，
\verb@let@も削ることができる．

最終結果は始めのものより短く，理解も容易だ．
元のコードでは最後に\verb@(list 'a sqr)@という式が現れたが，
これでは\verb@sqr@の値がどこから来るのかすぐには明らかにならなかった．
今は返り値の元になるものは道路地図のように目の前に広がっている．

この章での例は短いものだったが，この方法のスケールは次第に拡大する．
実際，大規模な関数に適用すればそれだけ価値が出てくる．
副作用を起こす関数でさえ，副作用を起こさないパーツへときれいに分解できる．
%}}}
\subsection{関数的インタフェイス}   %{{{
副作用が起こす問題には大きいものと小さいものがある．
例えば次の関数では\verb@nconc@を呼んでいるが，参照透明性は保たれている
\footnote{参照透明性の定義についてはpoohページを参照．}．
\begin{verbatim}
(defun qualify (expr)
  (nconc (copy-list expr) (list 'maybe)))
\end{verbatim}
これを任意の引数で呼んでも，引数が同じなら必ず同じ（\verb@equal@を満たす）値を返す．
呼び出し側から見れば\verb@qualify@は純粋な関数的コードであるも同然だ．
そのことは，実際に引数を書き換えてしまう\verb@bad-reverse@（kaboomページ）
には当てはまらない．

全ての副作用を一括りに悪者にする代わりに，
問題のある場合とない場合を区別する方法があれば便利だろう．
大雑把に言うと，関数が，他の誰のものでもないオブジェクトを書き換えるのは無害だ．
例えば\verb@qualify@内の\verb@nconc@は無害だと言える．
それは第1引数として与えられたリストは新たにコンシングされるからだ．
他のどの関数もそれに関わることはない．

一般的な場合では，オブジェクトをどの関数が支配しているかではなく，
どの関数呼び出しが支配しているかについて考えなければいけない．
次の例では変数\verb@x@を支配しているものは他に何もないが，
呼び出しの作用は，次の呼び出し時に明らかになる．
\begin{verbatim}
(let ((x 0))
  (defun total (y)
    (incf x y)))
\end{verbatim}
だからルールはこうあるべきだ：
任意の関数呼び出しが，
自分だけが支配するオブジェクトを安全に書き換えられるようにする．

何が引数と返り値を支配するのだろう？
関数呼び出しは返り値として受け取るオブジェクトを支配するが，
引数として渡されるオブジェクトは支配しない，というのがLispの慣習のようだ．
引数に変更を加える関数は「破壊的」との呼び名で区別されるが，
返ってくるオブジェクトに変更を加える関数には特に呼び名がない．

例えば次の関数は慣習に従っている：
\begin{verbatim}
(defun ok (x)
  (nconc (list 'a x) (list 'c)))
\end{verbatim}
これは慣習に従わない\verb@nconc@を呼んでいるが，
\verb@nconc@が切り張りするリストは新しく作られたもので，
\verb@ok@に引数として渡されるリストとは違う．
だから\verb@ok@そのものに問題はない．

しかしこれが僅かに違って
\begin{verbatim}
(defun not-ok (x)
  (nconc (list 'a) x (list 'c)))
\end{verbatim}
と書かれていたら，
\verb@nconc@の呼び出しは\verb@not-ok@に渡された引数に変更を加えるだろう．
多くのLispプログラムはこの慣習を（少なくともローカルな範囲では）破っている．
しかし\verb@ok@で見たように，ローカルな範囲で慣習を破っても，
関数呼び出しが慣習を破ることにはならない．
そして上の条件を満たす関数は，純粋に関数的なコードの長所を多く保つだろう．

純粋に関数的なものと全く区別の付かないプログラムを書くには，
もう一つ条件を付け加えなければいけない．
関数は，このルールに従わない他のコードとオブジェクトを共有してはいけない．
例えば次の関数は副作用を持たない．
\begin{verbatim}
(defun anything (x)
  (+ x *anything*))
\end{verbatim}
この関数の返り値はグローバル変数 \verb@*anything*@ に依存する．
だから他の関数がこの変数の値を変えることがあれば，
\verb@anything@の返す値はどうとでもなりうる．

呼び出しても自分だけが関わるものにしか変更を加えないように書かれたコードは，
純粋に関数的なコードに引けを取らない．
上記の条件を全て満たす関数は，
少なくとも外部に関数的インタフェイスを提供している：
それを同じ引数で2回呼び出せば，同じ結果が得られる筈だ．
そして，次の章で見るように，これがボトムアップ・プログラミングに必須のポイントだ．

破壊的な操作の問題点の一つは，グローバル変数と同様，
それがプログラムのローカル性を損ないうる点だ．
関数的なコードを書いているときは，焦点を絞ることができる：
書いている関数から呼び出されたり，書いている関数を呼び出す関数だけを考えればいい．
何かに破壊的な変化を加えようとすると，この長所は失われてしまう．
その関数はどこで使ってもいい筈だったのに．

上記の条件は，純粋な関数的コードで得られる完全なローカル性を保証する訳ではないが，
状況は幾分なりとも改善される．
例えば次のように\verb@f@が\verb@g@を呼び出すものとしよう：
\begin{verbatim}
(defun f (x)
  (let ((val (g x)))
  ; ここでvalを書き換えていいものか？
  ))
\end{verbatim}
\verb@f@が\verb@val@に対して\verb@nconc@で何かを連結するのは安全だろうか？
\verb@g@がidentityのときはそうではない：
そのときは，元々は\verb@f@そのものに引数として渡されたものを書き換えてしまうだろう．

だからLispの慣習を確かに守っているプログラムでも，
\verb@f@内で何かを書き換えたいならその向こうを見通さなければいけないだろう．
と言っても，それ程遠くを見通す必要はない：
プログラム全体について心配しなくても，
\verb@f@の下の部分ツリー（subtree）だけを考慮すればいい．

上の慣習から導かれるのは，
関数は安全に書き換えられないものを返してはいけないということだ．
だから返り値にクォート付きオブジェクトを含むような関数を書くのは避けるべきだ．
ここで\verb@exclaim@を，その返り値がクォート付きリストを含むように定義し
\begin{verbatim}
(defun exclaim (expression)
  (append expression '(oh my)))
\end{verbatim}
呼び出し後に返り値に破壊的な操作をすると
\begin{verbatim}
> (exclaim '(lions and tigers and bears))
(LIONS AND TIGERS AND BEARS OH MY)
> (nconc * '(goodness))
(LIONS AND TIGERS AND BEARS OH MY GOODNESS)
\end{verbatim}
関数内のリストに変更を及ぼすことになりうる：
\begin{verbatim}
> (exclaim '(fixnums and bignums and floats))
(FIXNUMS AND BIGNUMS AND FLOATS OH MY GOODNESS)
\end{verbatim}
\verb@exclaim@をそういった問題に対して堅固なものにするには，こう書くべきだ：
\begin{verbatim}
(defun exclaim (expression)
  (append expression (list 'oh 'my)))
\end{verbatim}

関数がクォート付きリストを返すべきでないというルールには，大きな例外が1個ある：
マクロを生成する関数だ．
マクロ展開関数は，生成するマクロ展開がコンパイラにそのまま受け取られるなら，
その中にクォート付きリストを安全に含むことができる．

それ以外では，一般的に言ってクォート付きリストは疑っていい．
それらの多くは大抵\verb@in@（boomページ）等のマクロで実現すべきものだ．
%}}}
\subsection{インタラクティブ・プログラミング}   %{{{
前の章ではプログラムの構成のよい方法として関数的なプログラミング・スタイルを提示した．
しかし関数的プログラミング・スタイルはそれだけのものではない．
Lispプログラマは美的な理由だけで関数的プログラミング・スタイルを取っているのではない．
作業が簡単になるからそうするのだ．
Lispの動的な環境では，関数的プログラムは並外れた速さで書くことができ，
同時に並外れた信頼性が高い．

Lispではプログラムのデバッグは比較的簡単だ．
たくさんの情報が実行時に利用可能で，エラーの原因をトレースするのに役立つ．
しかしもっと重要なのは，プログラムをテストするときの簡単さだ．
プログラムをコンパイルして全体を一度にテストする必要がない．
関数はトップレベル・ループから個々に呼び出してテストできる．

テストを随時行うことには大変価値があるので，
Lispのプログラミング・スタイルはその長所を取り入れて進化してきた．
関数的プログラミング・スタイルで書かれたプログラムは関数1個毎に理解できるが，
読む方の側からはこれが大きな長所だ．
しかし関数的プログラミング・スタイルは，テストを随時行うことにも完全に適応している：
このスタイルで書かれたプログラムは関数1個毎にテストできる．
ある関数が外部を参照もせず，変更もしないなら，どんなバグもすぐに明らかになる．
そういった関数は返り値を通してのみ外部に影響を及ぼすのだ．
返り値が予想通りである限り，それを返したコードは信頼できる．

実際，熟練Lispプログラマはテストしやすいようにプログラムをデザインする：
\begin{enumerate}
    \item 彼らは副作用を使う部分を幾つかの関数に隔離し，
        プログラムの大部分は純粋に関数的なプログラミング・スタイルで書けるようにする．
    \item 関数が副作用を使うのを避けられないなら，
        彼らは少なくともそこに関数的インタフェイスを盛り込もうとする．
    \item 彼らは関数に明確な目的を一つだけ与える．
\end{enumerate}
関数を書くと，それを代表的な状況のどれかでテストし，済んだら次の状況に移る．
煉瓦がそれぞれ予想通りの仕事をすれば，壁はしっかり立つだろう．

Lispでは，壁自体もうまくデザインすることができる．
1分間の転送の遅れがある中で，遠く離れた誰かと会話するのを想像して欲しい．
次にとなりの部屋の誰かと会話するのを想像して欲しい．
同じ会話が速く済むだけではなく，会話の種類が変わるだろう．
Lispでは，ソフトウェア開発は面と向かって話をするようなものだ．
コードを書くにつれてテストができる．
そして簡単に方針転換できることは，
それが会話に及ぼすのと同じくらい劇的な影響をソフトウェア開発に及ぼす．
そのとき，同じプログラムを速く書いているだけではない．
別の種類のプログラムを書いているのだ．

それはどうやって？
テストが素早く済めば，もっと頻繁にテストができる．
Lispでは（他のどのプログラミング言語でもそうだが），
ソフトウェア開発はコード書きとテストのサイクルから成る．
しかしLispではサイクルがとても短い：
関数1個毎，いや関数の部分毎でもいい．
あらゆる部分を書くにつれてテストすれば，
エラーが起きたときにどこを見ればいいか分かるだろう：
最後に書いた部分だ．
単純に聞こえるが，この原則はボトムアップ・プログラミングを堅固なものにしている要因の
大きな割合を占めている．
それは更なる自信をもたらし， Lispプログラマは（少なくともある一時）
古い「計画－実装」スタイルのソフトウェア開発からフリーになれるのだ．

第1.1節では，ボトムアップ・デザインが進化するプロセスであることを強調した．
プログラミング言語を構築しつつ，それでプログラムを書くことができる．
このアプローチが有効なのは下部のコードを信頼できるときの話だ．
その層を本当にプログラミング言語として使いたいなら，
遭遇したバグはプログラミング言語そのものではなく自分のアプリケーション内にある，と
（他のプログラミング言語を使ったときと同じように）確信できるようでなくてはいけない．

だから新しく作った抽象的構造はこの重い責任を背負わなければならず，
しかもそれらは必要に応じて作られるようでなければいけない．
結構な話だ．
Lispでは両方が実現できる．
プログラムを関数的スタイルで書き，それを随時テストしていけば，
即座に目的を達せるような柔軟性と，
普通なら注意深く立てた計画と結びつけて考えられるような信頼性が得られる．
%}}}
%}}}
\section{ユーティリティ関数}    %{{{
Common Lispのオペレータは3種類に分かれる：
関数にマクロ（ユーザが作れるもの）と，特殊オペレータ（ユーザには作れない）だ．
この章では，Lispを新しい関数で拡張するテクニックを説明する．
しかしここで言う「テクニック」は普通の意味のものではない．
そういった関数について知るべき重要な点は，
それらをどうやって書くかということではなく，それらがどこから来たのかということだ．
Lispの拡張には，他の関数を書くときと大体同じテクニックが使われることになる．
そういった拡張を書くとき難しいのは，
どうやって書くかを決めることではなく，何を書くかを決めることだ．
\subsection{ユーティリティの誕生}   %{{{
一番単純な場合では，誰がユーザのLispをデザインしようと，
ボトムアップ・プログラミングとは後から付いた名前に過ぎない．
また同時に，ユーザはプログラムを書きながら，
プログラムを書き易くする新しいオペレータをLispに追加していく．
これらの新しく作られたオペレータはユーティリティと呼ばれる．

「ユーティリティ」という言葉に正確な定義などない．
ある短いコードがユーティリティと呼ばれるのは，
それが短すぎて独立のアプリケーションとは見なせず，
しかも用途が一般的過ぎてあるプログラムの一部とも見なせない場合だ．
例えば，データベース・プログラムはユーティリティにはならないが，
リストに単一の操作を行う関数はユーティリティになりうる．
大部分のユーティリティはLispが既に備えている関数やマクロに似ている．
実際，Common Lispの組み込みオペレータの多くはユーティリティとして生まれたものだ．
関数\verb@remove-if-not@はリストの要素のうちある述語を満たすものを全て集めるが，
Common Lispの一部になるまでの何年もの間，個々のプログラマによって使われていた．

ユーティリティの書き方は，
書くときのテクニックとするよりも心得とした方が上手く説明できる．
ボトムアップ・プログラミングとは，
プログラムとプログラミング言語を同時に書いていくことだ．
これを上手にこなすには，
プログラムにどのオペレータが欠けているかを鋭く感じる感覚を鍛えないといけない．
プログラムを見て，「ああ，あなたが本当に言いたいのはこれでしょう．」
と言えるようにならなくてはいけない．

例えば，ここで\verb@nicknames@が名前を引数に取り，
それから派生しうる愛称の全てをリストにまとめる関数だとしよう．
この関数が与えられたとき，
名前のリストから得られる愛称を全て集めるにはどうすればいいだろう？
Lispを学習中の誰かが次のようなコードを書くかもしれない：
\begin{verbatim}
(defun all-nicknames (names)
  (if (null names)
      nil
      (nconc (nicknames (car names))
        (all-nicknames (cdr names)))))
\end{verbatim}
経験を積んだLispプログラマは，こんな関数を見て
「ああ，本当に欲しいのは\verb@mapcan@だろ．」と言う．
それならある人々の愛称を全て探す新しい関数を定義して呼び出さなくても，1個の式で済む：
\begin{verbatim}
(mapcan #'nicknames people)
\end{verbatim}
\verb@all-nicknames@は車輪の再発明だ．
だが，それがまずいのはその点だけではない：
汎用オペレータで可能なことを特定の関数に埋もれさせてしまっている．

この場合オペレータ\verb@mapcan@は既に存在していた．
\verb@mapcan@を知っていた人は\verb@all-nicknames@を見ると少し変な気がしただろう．
ボトムアップ・プログラミングに上達するには，
使われていないオペレータがまだ書かれていないものだったとき，
同じような不快感を感じられるようにならなくてはいけない．
「本当に欲しいのは\verb@x@だろ．」と言えなくてはならず，
同時に\verb@x@がどういうものであるべきか分かっていなければならない．
Lispプログラミングは，何よりも必要に応じて新ユーティリティを生み出すことを必然的に伴う．
この章の狙いは，そういったユーティリティがどのように生まれるかを示すことだ．

ここで，\verb@towns@は近隣の街を近い方から順に並べたリストで，
\verb@bookshops@は市内の全ての書店のリストを返す関数だとしよう．
書店がある一番近い街と，その中の書店を探したいとき，まず次のものから始めよう：
\begin{verbatim}
(let ((town (find-if #'bookshops towns)))
  (values town (bookshops town)))
\end{verbatim}
しかしこれは少し格好悪い：\verb@find-if@が
「\verb@bookshops@が非nilの値を返すような要素」を見つけたときもその値は捨てられ，
\verb@find-if@から戻った直後に再びその値を求めるようになっている．
\verb@bookshops@の呼び出しのコストが大きいとすると，
慣用法に従ったこの方法は格好悪いばかりか非効率にもなるだろう．
不必要な処理を避けるため，代わりに次の関数を使う：
\begin{verbatim}
(defun find-books (towns)
  (if (null towns)
      nil
      (let ((shops (bookshops (car towns))))
        (if shops
            (values (car towns) shops)
            (find-books (cdr towns))))))
\end{verbatim}
\verb@(find-books towns)@の呼び出しでは，
少なくとも必要最低限の計算で望みの結果が出る．
しかしちょっと待て\wadash
いつか将来，再び似たような検索をしたくなることはないだろうか？
ここで本当に必要なのは，\verb@find-if@と，
発見された要素と比較関数の返り値の両方を返す何かの関数を結合するユーティリティだ．
そのようなユーティリティは
\begin{verbatim}
(defun find2 (fn lst)
  (if (null lst)
      nil
      (let ((val (funcall fn (car lst))))
        (if val
            (values (car lst) val)
            (find2 fn (cdr lst))))))
\end{verbatim}
として定義できる．
\verb@find-books@と\verb@find2@が似ていることに注意しよう．
実際，後者は前者の全体構造として表せる．
今，新しいユーティリティを使えば，最初の目的を1個の式で達成できる：
\begin{verbatim}
(find2 #'bookshops towns)
\end{verbatim}
Lispプログラミング独特の特徴の一つは，引数としての関数の重要性だ．
これはLispがボトムアップ・プログラミングに適している理由の一部だ．
関数の骨格を抽象化するのは，引数に関数を使うことで肉付けができるときには比較的簡単だ．

プログラミングの入門課程では，最初に「抽象化は二度手間の回避につながる」と教える．
その中の初歩の一つに「動作を重複させてはいけない」とある．
例えば，1～2個の定数に従って同じことをする関数を定数別に定義するのではなく，
1個の関数を定義し，それに定数を引数として与えればいい．

Lispでは関数全体を引数として渡せるので，この考えをさらに深めることができる．
前述の例の両方で，特定の関数から始めて，関数を引数に取る一般的な関数に進んだ．
1番目の例では既に定義されていた\verb@mapcan@を使い，
2番目の例では新しいユーティリティ\verb@find2@を書いたが，
全体的な原則は同じだ：
一般部分と個別部分を混ぜ合わせるのでなく，
一般部分を定義して個別部分を引数として渡すこと．

注意深く適用すれば，この原則は目覚ましい程エレガントなプログラムをもたらす．
ボトムアップ・プログラミングを支える力はそれだけではないが，これは主要なものだ．
この章で定義した32個のユーティリティのうち，18個が関数を引数に取ることができる．
%}}}
\subsection{抽象化への投資} %{{{
簡潔さがウィットの魂ならば，それはまた，効率と並んで，いいソフトウェアの真髄でもある．
プログラムを書いたり保守するのにかかるコストは，
プログラムが長くなるにつれて高まる\note{MaintainningCost}．
他の条件が同じなら，短いプログラムの方がいい．

この視点からは，ユーティリティの作成は主要な労力配分の対象と見なされるべきだ．
\verb@find-books@をユーティリティ\verb@find2@で置き換えた結果，
コードの行数は変わらなかった．
しかしある意味ではプログラムを短くしたことになった．
なぜならユーティリティの長さは現在製作中のプログラムの長さに加えなくてもいいからだ．

Lispの拡張を主要な労力配分の対象として扱うのは，単なる数字上のごまかしではない．
ユーティリティは独立したファイルに収めることもできる．
プログラム製作に従事しているときには，それらは私達の目を煩わせないし，
後でそのプログラムの何かを変更しないといけなくなったときにも，
それらの中身が関わってくることはまずないだろう．

しかし，主要な労力配分の対象として，ユーティリティには余分に注意を払わないといけない．
それは上手く書けていることが特に重要だ．
繰り返し使われるものだから，間違いや非効率な動作も繰り返されるだろう．
そのデザインにも余分な注意が必要だ：
新しいユーティリティは，目前の問題だけではなく一般的な状況に対して書かなければいけない．
最後に，その他の主要な労力配分の対象と同様，慌てて書いてはいけない．
新しい何かのオペレータを生み出そうと考えているが，
別のときに必要になるかどうかよく分からないときは，それを書いてしまうこと．
しかし，それを使う特定のプログラム内にまだ置いておくのだ．
その後，他のプログラムでその新オペレータを使うことがあれば，
それをサブルーチンからユーティリティへ昇格させて広く利用可能にすればいい．

ユーティリティ\verb@find2@はよい投資だったようだ．
7行の投資をすることで即座に7行が節約できた．
ユーティリティというものは，1回使うだけで元が取れる．
Guy Steeleの言葉に，プログラミング言語は
「私達の持つ簡潔さへの自然な傾向と協調」しなければならない，とある．
\begin{quote}
\dots プログラミング構造のコストはプログラマの強いられた苦労の量に比例する，
と信じがちだ
（ここで「信じる」という言葉は，熱烈な確信ではなく無意識の傾向という意味で使った）．
実際，プログラミング言語デザイナがこの精神的原則を心に留めておくのは
悪いことではない\note{belief}．
加算操作をコストの低いものと思う理由の一つは，
それを1文字\,``\verb@+@''\,で表記できることだ．
あるプログラミング構造に高いコストがかかるとは思っても，
それがコード書きの労力を半分にしてくれるなら，
しばしばコストの低いものよりそちらが好まれる．
\end{quote}
どのプログラミング言語でも「簡潔さへの傾向」は，
それを新しいユーティリティに適応させられる柔軟性がない限り，問題の種になる．
一番短い慣用法が一番効率的なことは滅多にない．
あるリストが別のリストより長いかどうか知りたいとき，素のままのLispでは
\begin{verbatim}
(> (length x) (length y))
\end{verbatim}
と書きたくなる．
ある関数を複数のリストの要素に適用したいときも，同様にリストを次のように連結したくなる：
\begin{verbatim}
(mapcar fn (append x y z))
\end{verbatim}
こうした例から，
ユーティリティはそれなしでは非効率的になってしまう状況に対して書くことが大事だと分かる．
適切なユーティリティによって補強されたプログラミング言語があれば，
一層抽象的なプログラムが書けるだろう．
更にそれらのユーティリティは，適切に定義されていれば，
効率的なプログラムを書けるよう導いてくれる．

ユーティリティ集は確実にプログラミングを簡単にしてくれる．
しかしユーティリティ集の役割はそれだけではない：
いいプログラムが書けるようにもしてくれる．
芸術の神は，コックと同じで，材料を目にした時点で行動に移る．
だから芸術家はアトリエ内にたくさんの道具や画材を持っておきたがるのだ．
彼らは，必要なものを手元にしっかり準備しておけば，新しいことを始め易いことを知っている．
同じ現象はボトムアップ・スタイルで書かれるプログラムでも現れる．
新しいユーティリティを書くと，それを予想より多く使うことに気付くだろう．
次の章では，数種類のユーティリティ関数を説明する．
それらは，どのような意味においても，
あなたがLispに追加したいと思うような関数の全ての種類を代表しているわけではない．
しかし，例示されたユーティリティはどれも現場で価値を証明されたものばかりだ．
%}}}
\subsection{リストに対する操作} %{{{
元々，リストはLispの主要なデータ構造だった．
事実，``Lisp''という名前は``LISt \mbox{Processing}''から来ている．
しかしLispがこの歴史上の事実のせいで誤解されては困る．
ポロシャツがポロ専用でないのと同じく，Lispはリスト操作用に生まれたのではない．
高度な最適化を施されたCommon Lispプログラムでは，リストを全く見かけないだろう．

しかし，Lispプログラムはコンパイル時にはやはりリストだ．
高度に洗練されたLispプログラムは実行時には余りリストを使わないが，
逆にその分，コンパイル時のマクロ展開を生成するときには多くのリストを使う．
だから現代のLisp方言ではリストの役割は減少したが，
リストに対する操作は依然としてLispプログラムの大きな部分を占めることがある．

\begin{figure}\begin{center}\begin{FramedVerb}
(proclaim '(inline last1 single append1 conc1 mklist))

(defun last1 (lst)
  (car (last lst)))

(defun single (lst)
  (and (consp lst) (not (cdr lst))))

(defun append1 (lst obj)
  (append lst (list obj)))

(defun conc1 (lst obj)
  (nconc lst (list obj)))

(defun mklist (obj)
  (if (listp obj) obj (list obj)))
\end{FramedVerb}\end{center}
\caption{リストに作用する小さな関数}
\label{fig:SmallF}
\end{figure}

第\ref{fig:SmallF}図と第\ref{fig:LargeF}図には，
リストを生成したりリストに関する条件判断を行う関数を幾つか示した．
第\ref{fig:SmallF}図のものは，定義する価値のあるユーティリティの中でも最小規模のものだ．
効率性のため，それらにはみなインライン宣言をするべきだ．

1番目の\verb@last1@はリストの最後の要素を返す．
組み込み関数\verb@last@が返すのはリストの最後のコンスで，最後の要素ではない．
\verb@last@を使うのは大抵\verb@(car (last ...))@として最後の要素を得るためだ．
そんな場合に新しいユーティリティを書く価値があるだろうか？
そう，それが実質的に組み込み関数の代わりになるようなときは書く価値がある．
\verb@last1@はエラー・チェックをしないことに注意すること．
一般的には，この本で定義されたコードはどれもエラー・チェックをしない．
これは例を簡潔にするためもあるが，
短いユーティリティ内ではとにかくエラー・チェックを一切しない方が理に適っている．
もし次のようにすると
\begin{verbatim}
> (last1 "blub")
>>Error: "blub" is not a list.
Broken at LAST...
\end{verbatim}
エラーは\verb@last@自身に捉えられる．
ユーティリティが小さいときは，それが形成する抽象化の層は大変薄く，ほとんど透明だ．
薄い氷の向こうが透けて見えるように，
\verb@last1@のようなユーティリティの向こうは透けて見えるので，
その背後の関数で起きたエラーは解釈することができる．

関数\verb@single@は引数が1個の要素を持つリストかどうかを調べる．
Lispのプログラムではこれをかなり頻繁に調べなくてはならない．
最初はつい人間語からの自然な翻訳を使いがちだ：
\begin{verbatim}
(= (length lst) 1)
\end{verbatim}
こうして調べるのはとても非効率的だ．
第1要素を見終わった直後にはもう必要な情報は分かっているからだ．

次は\verb@append1@と\verb@conc1@だ．
両方ともリストの末尾に新しい要素を付け加えるが，後者は破壊的だ．
これらの関数は小さいが，大変頻繁に使われるので定義しておく価値はある．
実際，\verb@append1@は以前のLisp方言では組み込み関数だった．

\verb@mklist@も（少なくとも）Interlispでは組み込み関数だった．
これは引数がリストであるかどうかを確かめる．
Lispの関数の多くは，単一の値と複数の値のリストのどちらかを返すようになっている．
\verb@lookup@がそんな関数で，
\verb@data@というリストの要素全てについてそれを呼び出した結果を集めたいとしよう．
それは次のようにすれば可能だ：
\begin{verbatim}
(mapcan #'(lambda (d) (mklist (lookup d)))
        data)
\end{verbatim}
第\ref{fig:LargeF}図にはリスト用ユーティリティの長めの例が示されている．
1番目は長いが，抽象性もさることながら効率の面から見ても有益なものだ．
それは2個の連続構造(sequence)を比較し，1番目の方が長いときのみ真を返す．
2個のリストの長さを比較したいとき，つい次のようにしたくなる：
\begin{verbatim}
(> (length x) (length y))
\end{verbatim}
この慣用法は，両方のリスト全体を探索しているので非効率だ．
もし片方の方がずっと長ければ，その差の部分を探索した手間は無駄になってしまう．
\verb@longer@のように2個のリストを並行的に探索する方が速い．

\verb@longer@の中には2個のリストの長さを比べる再帰関数が埋め込まれている．
\verb@longer@は長さを比べるためのものだから，
その再帰関数は\verb@length@の引数に与えられるもの全てに対して機能するべきだ．
しかし並行的に長さを比較することができるのはリストに適用されたときだけなので，
内部の再帰関数は引数が両方リストだったときのみ呼び出される．

次の関数\verb@filter@の性質は，
\verb@find-if@に対する\verb@remove-if-not@の性質と似ている．

組み込み関数\verb@remove-if-not@の返り値は，
\verb@find-if@に関数を渡してリストの連続したcdr部に適用したときの返り値全体と同じだ．
それと似たように，
\verb@filter@の返り値は，ある関数がリストの連続したcdr部に対して返すものと同じだ：
\begin{verbatim}
> (filter #'(lambda (x) (if (numberp x) (1+ x)))
    '(a 1 2 b 3 c d 4))
(2 3 4 5)
\end{verbatim}
\verb@filter@は関数と1個のリストを取り，
その関数がリストに適用されたときに非nil値が返されるような要素全てをリストにして返す．

\verb@filter@は，第2.8節の末尾再帰関数と同様な総和変数を使っている点に注意して欲しい．
実際，末尾再帰関数を書くことの狙いは，
コンパイラに\verb@filter@と同じ構造のコードを生成させることにある．
\verb@filter@に対しては，反復構造による直接的な定義の方が末尾再帰によるものより単純だ．
\verb@filter@の定義コード内での\verb@push@と\verb@nreverse@との組み合わせは，
Lispでリストの総和を求める際の一般的な慣用法だ．

\begin{figure}\begin{center}\begin{FramedVerb}
(defun longer (x y)
  (labels ((compare (x y)
                    (and (consp x)
                         (or (null y)
                             (compare (cdr x) (cdr y))))))
    (if (and (listp x) (listp y))
        (compare x y)
        (> (length x) (length y)))))

(defun filter (fn lst)
  (let ((acc nil))
    (dolist (x lst)
      (let ((val (funcall fn x)))
        (if val (push val acc))))
    (nreverse acc)))

(defun group (source n)
  (if (zerop n) (error "zero length"))
  (labels ((rec (source acc)
                (let ((rest (nthcdr n source)))
                  (if (consp rest)
                      (rec rest (cons (subseq source 0 n) acc))
                      (nreverse (cons source acc))))))
    (if source (rec source nil) nil)))
\end{FramedVerb}\end{center}
\caption{リストに作用する関数の大規模なもの}
\label{fig:LargeF}
\end{figure}

第\ref{fig:LargeF}図の最後の関数は，
リストを新しいリストの部分リストとしてまとめるものだ．
\verb@group@にリスト\verb@l@と数\verb@n@を与えると新しいリストが返され，
その中では\verb@l@の要素は長さ\verb@n@の部分リストにまとめられている．
余りは最後の部分リストに入る．
だから第2引数に2を与えると
\begin{verbatim}
> (group '(a b c d e f g) 2)
((A B) (C D) (E F) (G))
\end{verbatim}
という連想リストが得られる．
この関数は，末尾再帰形式（第2.8節）にするためにかなり入り組んだ方法で書かれている．
ラピッド・プロトタイピングの原則は，プログラム全体と同様に個々の関数にも適用できる．
\verb@flatten@のような関数を書くとき，可能な限り単純な実装方法から始めるのがいいだろう．
そして単純なものが正しく動作すれば，
必要に応じて効率的な末尾再帰版や反復版に変えることができる．
最初のものは（十分短ければ）コメントとして残せば，交換後の関数の動作の説明になる．
（\verb@group@や第\ref{fig:SmallF}図と第\ref{fig:LargeF}図内の他の関数の単純な実装は，
第vaomページ内のnoteに書かれている．）

\begin{figure}\begin{center}\begin{FramedVerb}
(defun flatten (x)
  (labels ((rec (x acc)
                (cond ((null x) acc)
                      ((atom x) (cons x acc))
                      (t (rec (car x) (rec (cdr x) acc))))))
    (rec x nil)))

(defun prune (test tree)
  (labels ((rec (tree acc)
                (cond ((null tree) (nreverse acc))
                      ((consp (car tree))
                       (rec (cdr tree)
                            (cons (rec (car tree) nil) acc)))
                      (t (rec (cdr tree)
                              (if (funcall test (car tree))
                                acc
                                (cons (car tree) acc)))))))
    (rec tree nil)))
\end{FramedVerb}\end{center}
\caption{2重再帰を使ったリスト・ユーティリティ}
\label{fig:Doubly-recursive}
\end{figure}

\verb@group@の定義は最低でも1種類のエラーチェックをする点で他と異なっている：
第2引数が0であるかどうかだ．
その場合，チェックをしないと無限の再帰に陥ってしまう．

この本の中の例は，ある1点で通常のLispの慣習から外れている：
それぞれの章を独立させるため，コード例は可能な限り素のLispで書かれている点だ．
しかし\verb@group@は例外だ．
これはマクロ定義に大変便利なので，この後の章でも数回再登場する．

第\ref{fig:LargeF}図の関数は，みなリストのトップレベル構造に沿って動作する．
第\ref{fig:Doubly-recursive}図には入れ子になったリスト内へ下っていく関数の例を2個示した．
1番目の\verb@flatten@もInterlispでは組み込み関数になっている．
これは引数のリストの要素であるか，要素の要素であるか，そのまた要素の\dots
といった全てのアトムのリストを返す．
\begin{verbatim}
> (flatten '(a (b c) ((d e) f)))
(A B C D E F)
\end{verbatim}
第\ref{fig:Doubly-recursive}図の2番目の関数\verb@prune@と\verb@istoremove-if@との関係は
\verb@copy-tree@と\verb@copy-list@との関係と似ている．
つまり，再帰的に部分リスト内へ下っていく：
\begin{verbatim}
> (prune #'evenp '(1 2 (3 (4 5) 6) 7 8 (9)))
(1 (3 (5)) 7 (9))
\end{verbatim}
引数として与えた関数が真を返す葉は全て除かれる．
%}}}
\subsection{検索}   %{{{
この章では，リストを検索する関数の例を幾つか与える．
Common Lispにはそのための組み込みオペレータが豊富にあるが，
それでも困難な\wadash 少なくとも効率的に実行するのは困難な\wadash 課題はある．
このことは第pumpページで説明した仮想的な状況の中で既に見た\note{HypotheticalCase}．
第\ref{fig:SearchLists}図の1番目の関数\verb@find2@は，それへの回答として作られたものだ．

\begin{figure}\begin{center}\begin{FramedVerb}
(defun find2 (fn lst)
  (if (null lst)
    nil
    (let ((val (funcall fn (car lst))))
      (if val
          (values (car lst) val)
          (find2 fn (cdr lst))))))

(defun before (x y lst &key (test #'eql))
  (and lst
       (let ((first (car lst)))
         (cond ((funcall test y first) nil)
               ((funcall test x first) lst)
               (t (before x y (cdr lst) :test test))))))

(defun after (x y lst &key (test #'eql))
  (let ((rest (before y x lst :test test)))
    (and rest (member x rest :test test))))

(defun duplicate (obj lst &key (test #'eql))
  (member obj (cdr (member obj lst :test test))
          :test test))

(defun split-if (fn lst)
  (let ((acc nil))
    (do ((src lst (cdr src)))
      ((or (null src) (funcall fn (car src)))
       (values (nreverse acc) src))
      (push (car src) acc))))
\end{FramedVerb}\end{center}
\caption{リストを検索する関数}
\label{fig:SearchLists}
\end{figure}

次のユーティリティ\verb@before@は似た意図を持って書かれた．
これはあるオブジェクトがリスト内で別のオブジェクトよりも先に現れるかどうかを調べる：
\begin{verbatim}
> (before 'a 'b '(a b c d))
(B C D)
\end{verbatim}
これを素のLispを使って愚直に調べることも十分簡単だ：
\begin{verbatim}
(< (position 'a '(a b c d)) (position 'b '(a b c d)))
\end{verbatim}
しかしこの慣用法は非効率だし，エラーにつながり易い．
非効率な理由は，この関数は本当は両方のオブジェクトを見つける必要はなく，
先に現れるものだけを見つければいいからだ．
またエラーにつながるというのは，オブジェクトがどちらもリスト内にないとき，
nilが \verb@<@ に引数として渡されてしまうからだ．
\verb@before@を使えば両方の問題が解決する．

\verb@before@の精神は集合への所属関係を調べることに似ているので，
組み込み関数\verb@member@に似せて書かれた．
\verb@member@と同様に比較関数（デフォルトでは\verb@eql@）をオプショナル引数として取る．
また，ただtを返すだけでなく，
第1引数で与えられたオブジェクトで始まるcdr部という，有益な情報を含んだ値を返す：

\verb@before@が真を返すのは，
第2引数を見つける前に第1引数を見つけたときだということに注意．
そのため，第2引数がリスト内に存在しないときには真が返される：
\begin{verbatim}
> (before 'a 'b '(a))
(A)
\end{verbatim}
もっと精密に調べるには，\verb@after@
（引数が両方リスト内に存在しないと真を返さない）を使う：
\begin{verbatim}
> (after 'a 'b '(b a d))
(A D)
> (after 'a 'b '(a))
NIL
\end{verbatim}
\verb@(member o l)@がリスト\verb@l@内に\verb@o@を見つけたとき，
ただのtでなく\verb@o@で始まる\verb@l@のcdr部を返す．
この返り値は，例えば重複して存在するオブジェクトを調べるために使える．
\verb@l@内に\verb@o@が重複して存在していると，
それは\verb@member@の返したリストのcdr部内にも存在する．
この慣用法は次のユーティリティ\verb@duplicate@内に埋め込まれている：
\begin{verbatim}
> (duplicate 'a '(a b c a d))
(A D)
\end{verbatim}
重複を調べるユーティリティは同じ原則に基づいて他にも定義できる．
潔癖性のプログラミング言語デザイナは，
Common Lispでは「偽」と「空リスト」の両方をnilで表すことに衝撃を受ける．
確かにそれが問題を起こすこともある（第14.2章を参照）が，
\verb@duplicate@等の関数では便利だ．
連続構造の包含関係を問うとき，
偽であることを空の連続構造として表現するのは自然に思える．
第\ref{fig:SearchLists}図の最後の関数も，\verb@member@の一般化の一種だ．
\verb@member@は，それが発見した要素から始まるリストのcdr部を返すのに対し，
\verb@split-if@は元のリストの前半分もあわせて返す．
このユーティリティは，主に何かの順番で整列されたリストに対して使われる：
\begin{verbatim}
> (split-if #'(lambda (x) (> x 4))
            '(1 2 3 4 5 6 7 8 9 10))
(1 2 3 4)
(5 6 7 8 9 10)
\end{verbatim}

\begin{figure}\begin{center}\begin{FramedVerb}
(defun most (fn lst)
  (if (null lst)
      (values nil nil)
      (let* ((wins (car lst))
             (max (funcall fn wins)))
        (dolist (obj (cdr lst))
          (let ((score (funcall fn obj)))
            (when (> score max)
              (setq wins obj
                    max score))))
        (values wins max))))

(defun best (fn lst)
  (if (null lst)
      nil
      (let ((wins (car lst)))
        (dolist (obj (cdr lst))
          (if (funcall fn obj wins)
              (setq wins obj)))
        wins)))

(defun mostn (fn lst)
  (if (null lst)
      (values nil nil)
      (let ((result (list (car lst)))
            (max (funcall fn (car lst))))
        (dolist (obj (cdr lst))
          (let ((score (funcall fn obj)))
            (cond ((> score max)
                   (setq max score
                         result (list obj)))
                  ((= score max)
                   (push obj result)))))
        (values (nreverse result) max))))
\end{FramedVerb}\end{center}
\caption{要素を比較する検索関数}
\label{fig:CompareElements}
\end{figure}

第\ref{fig:CompareElements}には別の種類の検索関数が載っている：
要素同士を比較する関数だ．
最初の\verb@most@は要素を1度に1個ずつ調べる．
これはリストと点数付け関数を引数に取り，最高点を与える要素を返す．
等しい点を与える要素があったときは，リスト内で最初に現れたものを返す．
\begin{verbatim}
> (most #'length '((a b) (a b c) (a) (e f g)))
(A B C)
3
\end{verbatim}
\verb@most@は返した要素の与えた（最高）点も返す（その方が便利だ）．

もっと一般的な種類の検索には\verb@best@を使う．
このユーティリティも関数とリストを引数に取るが，
これに使う関数は2個の引数を取る述語でなければいけない．
返り値は1個の要素で，述語がその他の要素全てに対して勝っていると判断するものだ．
\begin{verbatim}
> (best #'> '(1 2 3 4 5))
5
\end{verbatim}
\verb@best@は\verb@sort@の結果のcar部と見ることもできるが，
こちらの方がずっと効率がいい．
リスト内の要素に完全な順位を定義する述語を提供するかどうかは呼び出し側次第だ．
そうでなければ要素の並び順は結果に影響し，
\verb@most@と同様，等しい点が出たときには最初の要素が返される．

最後の\verb@mostn@は点数付け関数とリストを引数に取り，
関数が最高点を付ける要素全てから成るリスト（と最高点）を返す：
\begin{verbatim}
> (mostn #'length '((a b) (a b c) (a) (e f g)))
((A B C) (E F G))
3
\end{verbatim}
%}}}
\subsection{対応付け}   %{{{
広く使われるLispの関数の種類には，他に対応付け関数\wadash
ある関数を複数の引数に適用するもの\wadash がある．
第\ref{fig:Mapping1},~\ref{fig:Mapping2}図には新しい対応付け関数の例を示した．
最初の3個は関数をある範囲の数に（それらの数を含むリストをコンシングせずに）
適用するためのものだ．
最初の2個，\verb@map0-n@と\verb@map1-n@は，正の整数の範囲で動作する：
\begin{verbatim}
> (map0-n #'1+ 5)
(1 2 3 4 5 6)
\end{verbatim}
両方ともさらに一般的な\verb@mapa-b@（任意の範囲の数に対して動作する）
を使って定義されている．
\begin{verbatim}
> (mapa-b #'1+ -2 0 .5)
(-1 -0.5 0.0 0.5 1.0)
\end{verbatim}
\verb@mapa-b@の次はさらに一般的な\verb@map->@で，
これは任意のオブジェクトの連続構造に対して機能する．
連続構造は第2引数で与えられたオブジェクトから始まり，
第3引数で与えられたオブジェクトで終わって，
その間のオブジェクトは第4引数で与えられた関数によって生成される．
\verb@map->@を使うと，数の連続への操作と同様に，任意のデータ構造を扱うことが可能だ．
\verb@mapa-b@は\verb@map->@を使うと次のように定義できる：
\begin{verbatim}
(defun mapa-b (fn a b &optional (step 1))
  (map-> fn
         a
         #'(lambda (x) (> x b))
         #'(lambda (x) (+ x step))))
\end{verbatim}
組み込み関数\verb@mapcan@は効率のために破壊的関数として作られている．
それは次のようにして定義できる：
\begin{verbatim}
(defun our-mapcan (fn &rest lsts)
  (apply #'nconc (apply #'mapcar fn lsts)))
\end{verbatim}
\verb@mapcan@は\verb@nconc@を使ってリストをつなぎ合わせているので，
第1引数によって返されるリストは新しく作られたものの方がいい．
そうしないと次にそのリストを使うときには変更を受けていることだろう．
\verb@nicknames@（doveページ）が，
愛称の「リストを生成する」関数として定義されたのはそういった理由による．
それがただどこかに保持されたリストを返すだけなら，
\verb@mapcan@を使うのは安全でなくなるだろう．
代わりに，返されたリストをつなぎ合わせるのには\verb@append@を使わなければならなくなる．
そのような場合のため，\verb@mappend@は「非破壊的な\verb@mapcan@」を提供する．

次のユーティリティ\verb@mapcars@が使われるのは，
\verb@mapcar@で関数を適用したいリストが複数あるときだ．
ここで数のリストが2個あり，両方のリストの要素の平方根から成る1個のリストが欲しいとしよう．
素のLispを使って
\begin{verbatim}
(mapcar #'sqrt (append list1 list2))
\end{verbatim}
とすれば実現できるが，そうすると不必要なコンシングが行われている．
\verb@list1@と\verb@list2@とをつなぎ合わせても，その結果はすぐに捨てられてしまう．
\verb@mapcars@を使うと
\begin{verbatim}
(mapcars #'sqrt list1 list2)
\end{verbatim}
によって同じ結果が得られ，不必要なコンシングは行われていない．

\begin{figure}\begin{center}\begin{FramedVerb}
(defun map0-n (fn n)
  (mapa-b fn 0 n))

(defun map1-n (fn n)
(mapa-b fn 1 n))

(defun mapa-b (fn a b &optional (step 1))
  (do ((i a (+ i step))
       (result nil))
    ((> i b) (nreverse result))
    (push (funcall fn i) result)))

(defun map-> (fn start test-fn succ-fn)
  (do ((i start (funcall succ-fn i))
       (result nil))
    ((funcall test-fn i) (nreverse result))
    (push (funcall fn i) result)))
\end{FramedVerb}\end{center}
\caption{対応付け関数1}
\label{fig:Mapping1}
\end{figure}

\begin{figure}\begin{center}\begin{FramedVerb}
(defun mappend (fn &rest lsts)
  (apply #'append (apply #'mapcar fn lsts)))

(defun mapcars (fn &rest lsts)
  (let ((result nil))
    (dolist (lst lsts)
      (dolist (obj lst)
        (push (funcall fn obj) result)))
    (nreverse result)))

(defun rmapcar (fn &rest args)
  (if (some #'atom args)
      (apply fn args)
      (apply #'mapcar
             #'(lambda (&rest args)
                 (apply #'rmapcar fn args))
             args)))
\end{FramedVerb}\end{center}
\caption{対応付け関数2}
\label{fig:Mapping2}
\end{figure}

第\ref{fig:Mapping2}図の最後の関数は，\verb@mapcar@のツリー対応版だ．
\verb@rmapcar@という名前は``recursive（再帰的） mapcar''の省略で，
これは\verb@mapcar@が単層リストに対して行う操作をツリーに対して行う：
\begin{verbatim}
> (rmapcar #'princ '(1 2 (3 4 (5) 6) 7 (8 9)))
123456789
(1 2 (3 4 (5)6)7 (8 9))
\end{verbatim}
これは\verb@mapcar@と同様，複数のリストを引数に取れる．
\begin{verbatim}
> (rmapcar #'+ '(1 (2 (3) 4)) '(10 (20 (30) 40)))
(11 (22 (33) 44))
\end{verbatim}
この後で登場する関数のうち幾つか（第prepページの\verb@rep@等）は，
本当は\verb@rmapcar@を使うべきものだ．

伝統的なリストの対応付け関数は，\textsf{CLtL2}で導入された数列マクロにより，
時代遅れなものとしてある程度置き換えられた．
例えば
\begin{verbatim}
(mapa-b #'fn a b c)
\end{verbatim}
は次のように変えることができる：
\begin{verbatim}
(collect (#Mfn (scan-range :from a :upto b :by c)))
\end{verbatim}
しかし対応付け関数への需要はまだある．
場合によっては対応付け関数の方が明確でエレガントなことがある．
\verb@map->@で表現できるものも数列では表現し辛いこともある．
最後に，対応付け関数は引数として渡すことができる（関数としての性質）．
%}}}
\subsection{入出力} %{{{
\begin{figure}\begin{center}\begin{FramedVerb}
(defun readlist (&rest args)
  (values (read-from-string
            (concatenate 'string "("
                         (apply #'read-line args)
                         ")"))))

(defun prompt (&rest args)
  (apply #'format *query-io* args)
  (read *query-io*))

(defun break-loop (fn quit &rest args)
  (format *query-io* "Entering break-loop.~%")
  (loop
    (let ((in (apply #'prompt args)))
      (if (funcall quit in)
          (return)
          (format *query-io* "~A~%" (funcall fn in))))))
\end{FramedVerb}\end{center}
\caption{入出力関数}
\label{fig:IO}
\end{figure}

第\ref{fig:IO}図では\textsf{I/O}ユーティリティの例を3個示した．
この種のユーティリティへの需要はプログラム毎にまちまちだ．
第\ref{fig:IO}図のものは代表的な例に過ぎない．
1番目のものはプログラムのユーザに括弧なしで式を入力させたいときに使う．
これは1行分の入力を読み取り，それをリストとして返す：
\begin{verbatim}
> (readlist)
Call me "Ed"
(CALL ME "Ed")
\end{verbatim}
\verb@values@を呼び出すことで返り値を1個に限定している
(\verb@read-from-string@自身，ここでは無駄な第2値を返す）．

関数\verb@prompt@は質問の表示と回答の読み取りを統合したものだ．
これは\verb@format@に対する引数と同じもの
（ただしストリーム指定用の第1引数以外）を引数に取る．
\begin{verbatim}
> (prompt "Enter a number between ~A and ~A.~%>> " 1 10)
Enter a number between 1 and 10.
>> 3
3
\end{verbatim}
最後の\verb@break-loop@を使うのはLispのトップレベルを真似たいときだ．
これは引数に2個の関数とレスト引数（プロンプトとして繰り返し渡される）を取る．
2番目の関数が入力に対して偽を返す限り，1番目の関数が入力に適用される．
だから，例えば実際のLispのトップレベルは次のように模倣できる：
\begin{verbatim}
> (break-loop #'eval #'(lambda (x) (eq x :q)) ">> ")
\end{verbatim}
すると\verb@break-loop@の中に入る．
\begin{verbatim}
>> (+ 2 3)
5
>> :q
:Q
\end{verbatim}
ところで，Common Lispのヴェンダが一般的に実行時ライセンスを主張するのはこれが理由だ．
実行時に\verb@eval@を呼べば，任意のLispプログラムがLisp自身を包含できる．
%}}}
\subsection{シンボルとストリング}   %{{{
シンボルとストリングは大変近い関係にある．
表示関数と読み取り関数の手段として，二つの表現は混用できる．
第\ref{fig:SymbolsAndStrings}図にはこの境界で動作するユーティリティの例を示した．
最初の\verb@mkstr@は任意の数の引数を取り，
それらの印字表現を連結してストリングとして返す：
\begin{verbatim}
> (mkstr pi " pieces of " 'pi)
"3.141592653589793 pieces of PI"
\end{verbatim}
\verb@symb@はそれに基づいて作られたもので，主にシンボルの生成に使われる．
これは1個以上の引数を取り，その印字名を連結したものを印字名とするシンボルを
（必要ならば新しく生成して）返す．
これは印字表現を持つ任意のオブジェクト\wadash
シンボル，ストリング，数，さらにリストまで\wadash を引数に取れる．
\begin{verbatim}
> (symb 'ar "Madi" #\L #\L 0)
|ARMadiLL0|
\end{verbatim}
\verb@mkstr@を呼んで引数をみな1個のストリングに連結した後，
\verb@symb@はそれを\verb@intern@に送る．
これはLispの伝統的なシンボル生成用関数で，
ストリングを引数に取り，そのストリングで表示されるシンボルを返すか，新しく生成する．
任意のストリングが（小文字や，括弧などのマクロ文字を含むものでも）
シンボルの印字名として使える．
シンボルの名前にそういった変わった文字が使われているときは，
名前は上のように縦棒に挟まれて表示される．
ソースコードでは，そういったシンボルは縦棒の間にあるか，
``\hbox{\texttt{\rlap{Y}\hss=\hss}}''が文字の前に付いていなければいけない：
\begin{verbatim}
> (let ((s (symb '(a b))))
(and (eq s '|(A B)|) (eq s '\(A\ B\))))
T
\end{verbatim}
次の関数\verb@reread@は，\verb@symb@の一般形だ．
オブジェクトの列を引数に取り，それらを表示し，再び読み込む．
これは\verb@symb@と同様にシンボルを返せるが，
他にも\verb@read@が返せるものなら何でも返せる．
リードマクロはシンボルの名前の一部としては扱われず，対応する関数が呼び出される．
また\verb@a:b@はカレント・パッケージの\verb@|a:b|@というシンボルではなく，
パッケージ\verb@a@内のシンボル\verb@b@として読み込まれる
\footnote{パッケージの紹介は，powページから始まる付章を参照．}．
一般的な関数は几帳面でもある：
\verb@reread@は，引数が正しいLisp文法に従っていないとエラーを発生する．

\begin{figure}\begin{center}\begin{FramedVerb}
(defun mkstr (&rest args)
  (with-output-to-string (s)
    (dolist (a args) (princ a s))))

(defun symb (&rest args)
  (values (intern (apply #'mkstr args))))

(defun reread (&rest args)
  (values (read-from-string (apply #'mkstr args))))

(defun explode (sym)
  (map 'list #'(lambda (c)
                 (intern (make-string 1
                                      :initial-element c)))
       (symbol-name sym)))
\end{FramedVerb}\end{center}
\caption{シンボルとストリングに作用する関数}
\label{fig:SymbolsAndStrings}
\end{figure}

第\ref{fig:SymbolsAndStrings}図の最後の関数は，昔の幾つかの方言では組み込み関数だった：
\verb@explode@はシンボルを引数に取り，
そのシンボルの名前に使われている文字から作られるシンボルから成るリストを返す．
\begin{verbatim}
> (explode 'bomb)
(B O M B)
\end{verbatim}
この関数がCommon Lispに含まれなかったのは偶々という訳ではない．
シンボルを分解したいようなときには，おそらく非効率的な作業をしているのだ．
しかし製品にするソフトウェアでなくてその原型の中なら，
この類のユーティリティを使う余地はある．
%}}}
\subsection{密度}   %{{{
コード内に多くの新ユーティリティを使うと，理解し辛いと言ってくる人がいる．
Lispをまだ使いこなせない人は素のLispしか読みとれない．
そういう人は拡張可能なプログラミング言語という考えが全く身に付いていないのだ．
そういう人がユーティリティをふんだんに使ったプログラムを目にすると，
その作者は全く変人で，
プログラムを一種の個人用プログラミング言語で書くことに決めてしまったと思うことだろう．

それらの新オペレータは，どれも（議論の余地はあるが）プログラムを読み辛くしてしまう．
プログラムを読み取れるようになる前に，それらのユーティリティを全て理解しなければいけない．
こういった言明がなぜ誤解されるのかについては，
popページで説明した例（一番近い書店を探した例）のことを考えてみて欲しい．
そのプログラムを\verb@find2@を使って書けば，
「プログラムを読み取れるようになる前に，
この新ユーティリティの定義を理解しなければいけないじゃないか．」
と不満を言う人が出てくる．
それでは，\verb@find2@を使わなかったとしてみよう．
すると\verb@find2@の定義は理解しなくてもいいが，
\verb@find-books@の定義を理解しなければいけない．
その中では\verb@find2@の仕事が「書店を見つける」という個別の課題と混ざっている．
\verb@find2@を理解するのはせいぜい\verb@find-books@と同じくらい難しいだけだ．
また，ここでは新ユーティリティは1回しか使っていない．
ユーティリティは繰り返し使うよう意図されたものだ．
実際のプログラムでは，\verb@find2@を理解しなければいけないか，
または3, 4個の特定目的の検索ルーチンを理解しなければいけないかの，どちらかの選択だろう．
前者の方が確実に簡単だ．

そう，ボトムアップ形式のプログラムを読み取るには，
作者の定義した新ユーティリティを全て理解しなければいけない．
しかしこれにかかる労力は，
ユーティリティなしの場合に必要なコードを理解しなければならないときの労力よりは，
ほとんど常に少ないだろう．
ユーティリティを使うとコードが読み辛くなると言う人がいたとすれば，
その人達はユーティリティを使わないとコードがどんなものになるか理解していないのだろう．
ボトムアップ・プログラミングは，それなしでは巨大なプログラムになった筈のものを，
小さくて単純なプログラムに見えるように変えてくれる．
こうするとそのプログラムは大した量の処理を行っていないとの印象を与え，
そのため理解が簡単になる筈だ．
Lispに未熟な人がコードをよく見て，実際はかなりの処理を行っていることに気付くと，
狼狽するのだ．

同じ現象は別の分野でも発見できる：
上手に設計された機械の部品は少ないが，より複雑に見える．
それは部品が狭い空間に詰め込まれているからだ．
ボトムアップ形式のプログラムは概念の密度が高い．
それは読み取るのに労力が必要かもしれないが，
それはプログラムがボトムアップ形式で書かれていなかったときに
必要になった筈の労力程ではない．
慎重に考えた上でユーティリティの使用を避けた方がいい場合が一つある：
コードの大部分とは独立して配布する小さなプログラムを書かなければいけないときだ．
ユーティリティというものは通常2, 3回使って始めて元が取れるものだが，
小規模なプログラムではユーティリティを含める意味がある程には使えないことがある．
%}}}
%}}}
\section{返り値としての関数}    %{{{
前章では，関数を引数として渡せることが抽象化への可能性をどれ程大きくするかを見た．
関数に対して行える操作が豊かな程，その可能性を深く利用できる．
新しい関数を生成して返す関数を定義することで，
関数を引数に取るユーティリティの効果を増幅できる．

この章で示すユーティリティは関数に対して動作する．
多くのユーティリティを式に対して動作するように書く方が（少なくともCommon Lispでは）自然だろう．
つまり，マクロとして書くのだ．
第15章では，これらのオペレータの幾つかにマクロの層が挿入される．
しかしそれらの関数が結局はマクロを通じてのみ呼び出されるとしても，
機能のどの部分が関数で実現できるのかを知ることは重要なことだ．
\subsection{Common Lispは進化する}  %{{{
Common Lispには元々コンプリメント関数(complement function)の対が幾つかある．
関数\verb|remove-|\hspace{1sp}\verb|if|と
\verb|remove-|\hspace{1sp}\verb|if-|\hspace{1sp}\verb|not|もそういった対の一つだ．
\verb@pred@が引数を1個取る述語だとすると
\begin{verbatim}
(remove-if-not #'pred lst)
\end{verbatim}
と
\begin{verbatim}
(remove-if #'(lambda (x) (not (pred x))) lst)
\end{verbatim}
とは等価だ．

引数として渡された関数をそうした関数に変えることで，もう片方の機能を複製できる．
そのとき，どうして両方の必要があるだろう？
\textsf{CLtL2}はそのような状況を意図した関数を新しく含んでいる：
\verb@complement@は述語\verb@p@を取り，常に反対の値を返す関数を返す．
\verb@p@が真を返すとき，コンプリメント関数は偽を返す．逆も同じだ．
すると\verb@complement@を使えば
\begin{verbatim}
(remove-if-not #'pred lst)
\end{verbatim}
は等価な
\begin{verbatim}
(remove-if (complement #'pred) lst)
\end{verbatim}
で置き換えられる．
\verb@-if-not@の類の関数を使い続けることを正当化する理由はほとんどない
\footnote{\texttt{remove-if-not}は別だろう．
これは\texttt{remove-if}よりも使われている．}．
実際\CLtL2 (p. 391) は，それらの使用は現在では推奨されないと記している．
それらがCommon Lispに残されるとしたら，その理由は互換性を保つために過ぎないだろう．

新しいオペレータ\verb|complement|は重要な主題\wadash
関数を返す関数\wadash の氷山の一角だ．
それはSchemeの慣用法の中では長らく重要な位置を占めていた．
Schemeは関数をレキシカルクロージャにした最初のLispで，
返り値に関数を使うことを興味深いものにしたのもそれだ．

ダイナミックスコープのLispでは関数を返せない訳ではない．
次の関数はダイナミックスコープのLispでもレキシカルスコープのLispでも
同じように動作するだろう：
\begin{verbatim}
(defun joiner (obj)
  (typecase obj
    (cons #'append)
    (number #'+)))
\end{verbatim}
これはオブジェクトを引数に取り，
その型に応じてそれらのオブジェクトを加え合わせる関数を返す．
これは数やリストに対して働く多態的な(polymorphic)連結関数の定義に使える：
\begin{verbatim}
(defun join (&rest args)
  (apply (joiner (car args)) args))
\end{verbatim}
しかし予め決めた中から選んで関数を返す程度が，
ダイナミックスコープの下でできることの限界だ．
実行時に関数を生成することは（上手には）できない．
\verb|joiner|は2個の関数の中どちらかを返せるが，返せる2個は固定されている．

これとは別にpropページで関数を返す関数を見た．
それはレキシカルスコープによるものだ：
\begin{verbatim}
(defun make-adder (n)
  #'(lambda (x) (+ x n)))
\end{verbatim}
\verb|make-adder|を呼ぶとクロージャが生成されるが，
その振る舞いは元々引数として与えられた値に依存する．
\begin{verbatim}
> (setq add3 (make-adder 3))
#<Interpreted-Function BF1356>
> (funcall add3 2)
5
\end{verbatim}
レキシカルスコープの下では，選択肢の中からどれかの関数を選ぶだけでなく，
実行時にクロージャを生成することができる．
ダイナミックスコープの下ではその技法は不可能だ
\footnote{ダイナミックスコープの下でも\texttt{make-adder}のようなものを作れるが，
それはまともに動作しないだろう．
返された関数が最終的に呼び出された環境に\texttt{n}の束縛が左右され，
制御することはできないだろう．}．
\verb|complement|がどのように書かれているかを考えれば，
それがクロージャを返す他ないということが分かる：
\begin{verbatim}
(defun complement (fn)
  #'(lambda (&rest args) (not (apply fn args))))
\end{verbatim}
\verb|complement|の返した関数は，
\verb|complement|が呼ばれた時点でのパラメータ\verb|fn|の値を使っている．
だから固定された選択肢の中から関数を選ぶだけでなく，
\verb|complement|はどの関数のコンプリメント関数でも求めに応じて生成できる：
\begin{verbatim}
> (remove-if (complement #'oddp) '(1 2 3 4 5 6))
(1 3 5)
\end{verbatim}

関数を引数として渡せることは抽象化のための強力な道具だ．
関数を返す関数が書けることで，それを最大限に利用できるようになる．
残りの節では関数を返すユーティリティの例を幾つか挙げる．
%}}}
\subsection{直交性}  %{{{
直交的(orthogonal)なプログラミング言語とは，
少数のオペレータを多数の様々な方法で結合させることで，
多様な意味が表現できるもののことだ．
おもちゃのブロックは極めて直交的だが，プラモデルはほとんど直交的でない．
\verb@complement@の主な長所は，プログラミング言語を一層直交的にしていることだ．
\verb|complement|の登場以前，
Common Lispには\verb@remove-if@と\verb@remove-if-not@，
\verb@subst-if@と\verb@subst-if-not@等の関数の組があった．
\verb@complement@があれば，それらの片方で事は足りる．

マクロ\verb@setf@もLispの直交性を高めている．
Lispの方言の古いものでは，データを読む関数と書く関数の組があったりしたものだ．
すると例えば属性リストがあれば，
属性を設定する関数が1個，求める関数がもう1個必要だろう．
Common Lispには後者に当たる\verb@get@しかない．
属性を設定するには\verb|get|を\verb@setf@と組み合わせて使う：
\begin{verbatim}
(setf (get 'ball 'color) 'red)
\end{verbatim}

Common Lispの体系そのものを小さくすることは難しいが，代わりにいい方法がある．
Common Lispの小規模な部分集合だけを使うことだ．
私達をこのゴールへ導いてくれる，
\verb@complement@や\verb@setf@等の新しいオペレータを定義できないものだろうか？
関数を組にまとめられる方法が少なくとも一つある．
多くの関数には等価で破壊的な別の関数がある．
\verb@remove-if@と\verb@delete-if@，\verb@reverse@と\verb@nreverse@，
\verb@append@と\verb@nconc@等だ．
ある関数と等価で破壊的な関数を返すオペレータを定義することで，
破壊的な関数を明示する必要がなくなる．

\begin{figure}\begin{center}\begin{FramedVerb}
(defvar *!equivs* (make-hash-table))

(defun ! (fn)
  (or (gethash fn *!equivs*) fn))

(defun def! (fn fn!)
  (setf (gethash fn *!equivs*) fn!))
\end{FramedVerb}\end{center}
\caption{等価で破壊的な関数を返す．}
\label{fig:DestructiveEquiv}
\end{figure}

第\ref{fig:DestructiveEquiv}図には「等価で破壊的な関数」の考えを補助するコードを示した．
グローバルなハッシュ表\,\verb@*!equivs*@\,は，
ある関数とそれに等価で破壊的な関数との対応付けを行う．
\verb@def!@\,によって等価で破壊的な関数を設定し，\verb@!@\,はそれを返す．
オペレータ\hskip\xkanjiskip\verb@!@（びっくりマーク）は，
Schemeで副作用のある関数の名前に\,\verb@!@\,を付け加える慣習から取った．
\begin{verbatim}
(def! #'remove-if #'delete-if)
\end{verbatim}
さて上のように定義してしまえば
\begin{verbatim}
(delete-if #'oddp lst)
\end{verbatim}
とする代わりに
\begin{verbatim}
(funcall (! #'remove-if) #'oddp lst)
\end{verbatim}
とすればいい．
ここではCommon Lispの造りがまずいせいでこの考えの元々の美点が隠れてしまっているが，
Schemeではもっとはっきり見える：
\begin{verbatim}
((! remove-if) oddp lst)
\end{verbatim}

直交性の向上もさることながら，オペレータ\,\verb@!@\,は他にも幾つかの利点をもたらす．
\verb@(! #'foo)@は\verb@foo@と等価で破壊的な関数だと見てすぐ分かるので，
プログラムがさらに簡潔になる．
また，破壊的な操作がソースコード内で目立って認識しやすい形を取るようになる．
それらはバグを探すときに特別な注意を払うべきものだから，これはいいことだ．

ある関数とそれに等価で破壊的な関数との関係は，普通は実行する前に明らかになるので，
\verb@!@\,はマクロとして定義するのが一番効率的だ．
そのためのリードマクロを定義してもいいだろう．
%}}}
\subsection{関数の値のメモワイズ}  %{{{
計算コストの高い関数を同じ引数で複数回呼び出したいときがあるなら，
値をメモワイズ(memoize)しておくのが得だ．
以前の返り値をみな保管しておき，
関数が呼び出される度にまず保管場所を見て，値が既に得られていないか調べる．

\begin{figure}\begin{center}\begin{FramedVerb}
(defun memoize (fn)
  (let ((cache (make-hash-table :test #'equal)))
    #'(lambda (&rest args)
        (multiple-value-bind (val win) (gethash args cache)
          (if win
              val
              (setf (gethash args cache)
                    (apply fn args)))))))
\end{FramedVerb}\end{center}
\caption{メモワイズユーティリティ．}
\label{fig:Memoizing}
\end{figure}

第\ref{fig:Memoizing}図には一般的なメモワイズユーティリティを示した．
\verb|memoize|に関数を渡すと，等価なメモワイズ機能付き関数が返る．
それは以前の返り値を蓄えるハッシュ表を持ったクロージャだ．
\begin{verbatim}
> (setq slowid (memoize #'(lambda (x) (sleep 5) x)))
#<Interpreted-Function C38346>
> (time (funcall slowid 1))
Elapsed Time = 5.15 seconds
1
> (time (funcall slowid 1))
Elapsed Time = 0.00 seconds
1
\end{verbatim}
メモワイズ機能付き関数では，呼び出しの繰り返しはハッシュ表の検索に過ぎない．
もちろん新しい値で呼んだときにも検索してしまうという余分な負荷はあるが，
十分計算コストの高い関数だけにメモワイズ機能を付けるのだから，
その負荷は比較すれば無視できると想定していいだろう．
さて上の\verb@memoize@の実装方法は大抵の場合には適しているが，幾つか制限もある．
呼び出し方を同じと見なすのは引数リストが\verb@equal@のときだが，
これは関数がキーワード引数を取るときには厳しすぎるだろう．
また返り値が1個の関数のみを想定していて，多値を蓄えたり返したりはできない．
%}}}
\subsection{関数を合成する}  %{{{
関数$f$のコンプリメント関数は$\sim\!\!f$と表記される．
第5.1節では$\sim$をLispの関数として定義するクロージャを示した．
関数に対してよく使われる操作には他に合成があり，$\circ$で表記される．
$f$と$g$が関数ならば$f\!\circ\!g$も関数で，$f\!\circ\!g(x)=f(g(x))$である．
これもクロージャでLispの関数として定義できる．

\begin{figure}\begin{center}\begin{FramedVerb}
(defun compose (&rest fns)
  (if fns
      (let ((fn1 (car (last fns)))
            (fns (butlast fns)))
        #'(lambda (&rest args)
                   (reduce #'funcall fns
                           :from-end t
                           :initial-value (apply fn1 args))))
      #'identity))
\end{FramedVerb}\end{center}
\caption{合成関数のためのオペレータ．}
\label{fig:FunctionalCompo}
\end{figure}

第\ref{fig:FunctionalCompo}図では関数\verb@compose@を定義した．
これは任意の数の関数を引数に取り，それらの合成を返す．
例えば
\begin{verbatim}
(compose #'list #'1+)
\end{verbatim}
が返すのは
\begin{verbatim}
#'(lambda (x) (list (1+ x)))
\end{verbatim}
と等価な関数だ．
\verb@compose@の引数に渡された関数は，
最後以外はみな引数が1個の関数でなければならない\note{last}．
最後の関数には制限は何もなく，それがどんな引数を取っても，
\verb|compose|の返す関数も同じ引数を取る．
\begin{verbatim}
> (funcall (compose #'1+ #'find-if) #'oddp '(2 3 4))
4
\end{verbatim}
\verb|not|がLispの関数なので，\verb|complement|は\verb|compose|の特殊形と言える．
それは
\begin{verbatim}
(defun complement (pred)
  (compose #'not pred))
\end{verbatim}
として定義できる．

\begin{figure}\begin{center}\begin{FramedVerb}
(defun fif (if then &optional else)
  #'(lambda (x)
      (if (funcall if x)
          (funcall then x)
          (if else (funcall else x)))))

(defun fint (fn &rest fns)
  (if (null fns)
      fn
      (let ((chain (apply #'fint fns)))
        #'(lambda (x)
            (and (funcall fn x) (funcall chain x))))))

(defun fun (fn &rest fns)
  (if (null fns)
      fn
      (let ((chain (apply #'fun fns)))
        #'(lambda (x)
            (or (funcall fn x) (funcall chain x))))))
\end{FramedVerb}\end{center}
\caption{関数生成方法の更なる例．}
\label{fig:FunctionBuilders}
\end{figure}

関数の組み合わせ方は合成だけではない．例えば
\begin{verbatim}
(mapcar #'(lambda (x)
            (if (slave x)
                (owner x)
                (employer x)))
        people)
\end{verbatim}
のような式をよく見かける．
このような関数を自動的に生成するオペレータが定義できる．
第\ref{fig:FunctionBuilders}図の\verb|fif|を使い
\begin{verbatim}
(mapcar (fif #'slave #'owner #'employer)
        people)
\end{verbatim}
とすれば同じ結果になる．

第\ref{fig:FunctionBuilders}図にはよく使われる種類の関数を生成する関数を幾つか示した．
2番目の\verb|fint|を使うのは次のようなときだ：
\begin{verbatim}
(find-if #'(lambda (x)
             (and (signed x) (sealed x) (delivered x)))
         docs)
\end{verbatim}
\verb|find-if|の第2引数に与えられた述語が，
その内部で呼ばれている3個の述語の共通部分を定義している．
\verb|fint|（``function intersection''関数の共通部分）を使えば
\begin{verbatim}
(find-if (fint #'signed #'sealed #'delivered) docs)
\end{verbatim}
と書ける．
同様に，関数集合の合併を返すオペレータも定義できる．
関数\verb|fun|は\verb|fint|と似ているが，\verb|and|でなく\verb|or|を使っている．
%}}}
\subsection{Cdr部での再帰}  %{{{
Lispのプログラムでは再帰関数は極めて重要なので，
それらを生成するユーティリティを定義しておいて損はない．
この章と次の章では，よく使われる2種類の再帰関数を生成する関数について説明する．
ただCommon Lispでは，これらの関数を使うのはまずい方法だ．
話題がマクロまで進めば，
この仕組みにさらにこなれた外見を与える方法を知ることになるだろう．
再帰関数を生成するマクロについては第15.2,~15.3章で議論する．

プログラム内に繰り返した形が現れるのは，より高いレベルの抽象的手法が使えることの印だ．
そういう形はLispプログラムの中では次のような関数より頻繁に見られる：
\begin{verbatim}
(defun our-length (lst)
  (if (null lst)
      0
      (1+ (our-length (cdr lst)))))
\end{verbatim}
または
\begin{verbatim}
(defun our-every (fn lst)
  (if (null lst)
      t
      (and (funcall fn (car lst))
           (our-every fn (cdr lst)))))
\end{verbatim}
これら2個は構造がかなり共通している．
共にリストの連続したcdr部に再帰的に作用し，毎回同じ式を評価している．
ベース・ケースでは別で，他とは違った値を返す．
この形はLispのプログラム内で大変頻繁に現れるので，
経験を積んだプログラマは思考を中断せずに読みこなしたり新しいのを書いたりできる．
実際，そういった形を新しい抽象化構造に組み込む方法はすぐに理解できる．

\begin{figure}\begin{center}\begin{FramedVerb}
(defun lrec (rec &optional base)
  (labels ((self (lst)
                 (if (null lst)
                     (if (functionp base)
                         (funcall base)
                         base)
                     (funcall rec (car lst)
                              #'(lambda ()
                                  (self (cdr lst)))))))
    #'self))
\end{FramedVerb}\end{center}
\caption{平坦なリストに対する再帰関数を定義する関数．}
\label{fig:FlatListRecur}
\end{figure}

しかし形そのものはみな同じだ．
これらの関数を手で書く代わりに，
自分のためにそれらを生成してくれる関数を書けるようになっておくべきだ．
第\ref{fig:FlatListRecur}図には\verb|lrec| (``list recurser'') という関数生成関数を示した．
これはリストの連続したcdr部に再帰的に作用する関数のほとんどを生成してくれる筈だ．
\verb|lrec|の第1引数は，その時点でのリストのcar部と，
再帰を続けるために呼ばれる関数という2個の引数を取る関数でなければならない．
\verb|lrec|を使えば，\verb|our-length|は
\begin{verbatim}
(lrec #'(lambda (x f) (1+ (funcall f))) 0)
\end{verbatim}
として表現できる．
リストの長さを得るには要素を調べたり途中で止まる必要はないので，
オブジェクト\verb|x|は常に無視してよく，常に関数\verb|f|を呼び出せばよい．
しかし\verb|our-every|を表現する可能性の利点は両方とも活用する必要がある．
例えば\verb|oddp|だ
\footnote{広く使われているあるCommon Lisp処理系では，
\texttt{functionp}は誤って\texttt{t}と\texttt{nil}に真を返す．
その処理系では\texttt{lrec}の第2引数に渡しても機能しないだろう．}：
\begin{verbatim}
(lrec #'(lambda (x f) (and (oddp x) (funcall f))) t)
\end{verbatim}
\verb|lrec|の定義では，\verb|self|というローカルな再帰関数を生成するために\verb|labels|を使った．
再帰途中に関数\verb|rec|に与えられる引数は，
その時点でのリストのcdr部と再帰呼び出しを形成する関数の2個だ．
\verb|our-every|等の再帰呼び出しを行う部分が最後に来る関数には，
第1引数が偽を返したその時点で止まって欲しい．
これは再帰呼び出しに渡された引数は値でなく，
必要があれば呼び出して値を求められる関数でなければならないということだ．

\begin{figure}\begin{center}\begin{FramedVerb}
; copy-list
(lrec #'(lambda (x f) (cons x (funcall f))))
; remove-duplicates
(lrec #'(lambda (x f) (adjoin x (funcall f))))
; find-if, for some function fn
(lrec #'(lambda (x f) (if (fn x) x (funcall f))))
; some, for some function fn
(lrec #'(lambda (x f) (or (fn x) (funcall f))))
\end{FramedVerb}\end{center}
\caption{\texttt{lrec}で表現された関数．}
\label{fig:lrec}
\end{figure}

第\ref{fig:lrec}図に示したのは，既存のCommon Lispの関数を\verb|lrec|を使って定義したものだ
\footnote{処理系によっては，これらの関数を表示する前に
\,\texttt{*print-circle*}\,を\texttt{t}に設定しなければならないかもしれない．}．

\verb|lrec|を使っても求める関数の最も効率のよい実装方法に必ず行き着く訳ではない．
実際，この章で定義されたような\verb|lrec|を始めとする再帰関数生成関数は，
末尾再帰による方法に一歩及ばないことが多い．
このためこれらはプログラム開発の初期のうちや，速度が重要でない箇所で使うのが一番だ．
%}}}
\subsection{部分ツリーでの再帰}  %{{{
\begin{figure}\begin{center}
\fbox{~\,\begin{minipage}{\FrameWidth}
\begin{center}
\begin{picture}(200,150)
\end{picture}\\
\hfill\texttt{(a.b)\hfill\hfill(a b c)\hfill\hfill(a b (c d))}\hfill~
\end{center}
\vspace{1.3em}
\end{minipage}~\,
}\end{center}
\caption{ツリーとしてのリスト．}
\label{fig:ListsAsTrees}
\end{figure}

Lispプログラムによく見られる再帰の形には他のものもある：部分ツリーに対する再帰だ．
この形は（おそらく入れ子になった）リストについて，
そのcar部とcdr部の両方を再帰的に下っていきたい場合に見られる．

Lispのリストは多目的な構造体で，
連続構造，集合，対応，配列，ツリーを含む色々なものを表現できる．
リストをツリーとして解釈する方法は幾つかある．
一番よく使われるのは，リストを二分ツリー（binary tree）に，
car部とcdr部をそれぞれ左右の枝に見なす方法だ．
（実際，リストの内部表現は大抵そうだ．）
第\ref{fig:ListsAsTrees}図にはリストとそれが表現するツリーの例を3個示した．
そういうツリーの内部節点はドット対（dotted-pair）表現したリストの点に対応するので，
リストをその形式で考えればツリーの構造は解釈しやすいだろう：
\begin{verbatim}
(a b c) = (a . (b . (c . nil)))
(a b (c d)) = (a . (b . ((c . (d . nil)) . nil)))
\end{verbatim}
どのリストも二分ツリーとして解釈できる．
そのため\verb|copy-list|と\verb|copy-tree|等のCommon Lispの関数の組がある．
前者はリストを連続構造としてコピーする．
リストが部分リストを含むとき，それは連続構造の要素に過ぎないのでコピーされない：
\begin{verbatim}
> (setq x '(a b)
        listx (list x 1))
((A B) 1)
> (eq x (car (copy-list listx)))
T
\end{verbatim}
それとは対照的に，\verb|copy-tree|はリストをツリーとしてコピーする．
部分リストは部分ツリーなので，やはりコピーされる：
\begin{verbatim}
> (eq x (car (copy-tree listx)))
NIL
\end{verbatim}
\verb|copy-tree|は次のように定義できる：
\begin{verbatim}
(defun our-copy-tree (tree)
  (if (atom tree)
      tree
      (cons (our-copy-tree (car tree))
            (if (cdr tree) (our-copy-tree (cdr tree))))))
\end{verbatim}
この定義は実は広く使われる形の一つだということが分かる．
（この後出てくる関数は形をはっきりさせるために少し妙な方法で書かれている．）
例えばツリーの葉を数えるユーティリティを考えてみよう：
\begin{verbatim}
(defun count-leaves (tree)
  (if (atom tree)
      1
      (+ (count-leaves (car tree))
         (or (if (cdr tree) (count-leaves (cdr tree)))
             1))))
\end{verbatim}
ツリーの持つ葉の数は，リストとして表現されたときに見えるアトムの数より多い：
\begin{verbatim}
> (count-leaves '((a b (c d)) (e) f))
10
\end{verbatim}
ツリーの持つ葉とは，ツリーをドット対表現で見たときに見えるアトムの全てだ．
ドット対表現では\verb|((a b (c d)) (e) f)|は4個のnilを含むが，
リスト表現ではそれらは見えない（括弧1組につき1個あるのだが）．
だから\verb|count-leaves|は10を返す．

前の章では，ツリーに作用するユーティリティを幾つか定義した．
例えば\verb|flatten|（jooページ）はツリーを引数に取り，
その中の全てのアトムをリストに括って返す．
つまり\verb|flatten|に入れ子になったリストを渡すと，
一番外側以外の括弧が無くなっただけのようなリストが返る：
\begin{verbatim}
> (flatten '((a b (c d)) (e) f ()))
(A B C D E F)
\end{verbatim}
この関数は（かなり非効率的だが）次のようにも定義できる：
\begin{verbatim}
(defun flatten (tree)
  (if (atom tree)
      (mklist tree)
      (nconc (flatten (car tree))
             (if (cdr tree) (flatten (cdr tree))))))
\end{verbatim}
最後に\verb|find-if|の再帰版であり，
平坦なリストだけでなくツリーにも作用できる\verb|rfind-if|について考えよう：
\begin{verbatim}
(defun rfind-if (fn tree)
  (if (atom tree)
      (and (funcall fn tree) tree)
      (or (rfind-if fn (car tree))
          (if (cdr tree) (rfind-if fn (cdr tree))))))
\end{verbatim}
\verb|find-if|をツリーにも作用するように一般化するには，
葉のみを検索するのか，それとも部分ツリー全体を検索するのかを決めなければならない．
ここでの\verb|rfind-if|は前者を採ることにする．
つまり呼び出し側は第1引数として渡された関数はアトムにのみ適用されると考えてよい：
\begin{verbatim}
> (rfind-if (fint #'numberp #'addp) '(2 (3 4) 5))
3
\end{verbatim}
\verb|copy-tree|，\verb|count-leaves|，\verb|flatten|に\verb|rfind-if|といった
4個の関数の構造は，何と似ていることだろう！
実際，それらはみな部分ツリーに作用する関数の典型的な例だ．
cdr部での再帰もそうだが，こういうものの原型を曖昧なままに放っておく事はない\wadash
そのインスタンスを生成する関数を書くことができる．

\begin{figure}\begin{center}\begin{FramedVerb}
(defun ttrav (rec &optional (base #'identity))
  (labels ((self (tree)
                 (if (atom tree)
                     (if (functionp base)
                         (funcall base tree)
                         base)
                     (funcall rec (self (car tree))
                              (if (cdr tree)
                                  (self (cdr tree)))))))
    #'self))
\end{FramedVerb}\end{center}
\caption{ツリーに対する再帰関数．}
\label{fig:RecurOnTree}
\end{figure}

原型そのものを掴むため，それらの関数をよく見て何が定型でないのかに注目しよう．
\verb|our-copy-tree|は本質的には2個の事実を表す：
\begin{enumerate}
\item 再帰の基底では引数をそのまま返す．
\item 再帰の途中では，左の部分ツリー（car部）での再帰結果と
    右の部分ツリー（cdr部）での再帰結果に\verb|cons|を適用する．
\end{enumerate}
そのため，これは2個の引数を取る関数生成関数の呼び出しとして表現できる：
\begin{verbatim}
(ttrav #'cons #'identity)
\end{verbatim}
\verb|ttrav| (``tree traverser'')の定義は第\ref{fig:RecurOnTree}図に示した．
再帰呼び出しのときは渡す値は1個でなく2個で，
それぞれ左の部分ツリーと右の部分ツリーに対して再帰を行う．
再帰の基底が関数のときは，
その関数はその時点での葉に対して呼ばれる．
平坦リストに対する再帰では基底の値は必ずnilだが，
ツリーに対する再帰では基底の値は有用であることがあり，
それを使いたくなることもあるかもしれない．

\begin{figure}\begin{center}\begin{FramedVerb}
; our-copy-tree
(ttrav #'cons)
; count-leaves
(ttrav #'(lambda (l r) (+ l (or r 1))) 1)
; flatten
(ttrav #'nconc #'mklist)
\end{FramedVerb}\end{center}
\caption{\texttt{ttrav}で表現された関数．}
\label{fig:Byttrav}
\end{figure}

\verb|ttrav|を使うと，これまで説明した関数は\verb|rfind-if|以外みな表現できる．
（第\ref{fig:Byttrav}図に示した．）
\verb|rfind-if|を定義するには，
いつ，どの場合に再帰呼び出しが行われるかを制御させてくれるような，
さらに一般的なツリー用再帰関数生成関数が要る．
\verb|ttrav|の第1引数には，再帰呼び出しの結果を取る関数を与えた．
一般的な状況においては，代わりに，
再帰呼び出しそのものを代表する2個のクロージャを取る関数を使う．
するとツリーの任意の深さまでのみを探索する再帰関数が書ける．

\verb|ttrav|によって生成された関数は必ずツリー全体を探索する．
\verb|count-leaves|や\verb|flatten|は
とにかくツリー全体を探索せざるを得ないのでそれでいいが，
\verb|rfind-if|には探す対象が見つかった時点で探索を止めて欲しい．
それにはさらに一般的な\verb|trec|（第\ref{fig:RecurOnTree}図）を使わなければならない．
\verb|trec|の第2引数は関数で，
再帰途中の時点でのオブジェクトと2個の再帰関数という3個の引数を取る．
それらの再帰関数はそれぞれ左右の部分ツリーに対する再帰を代表するクロージャだ．
\verb|trec|を使うと\verb|flatten|はこのように定義できる：
\begin{verbatim}
(trec #'(lambda (o l r) (nconc (funcall l) (funcall r)))
      #'mklist)
\end{verbatim}
以上より\verb|rfind-if|は\verb|oddp|によって以下のように表現できる：
\begin{verbatim}
(trec #'(lambda (o l r) (or (funcall l) (funcall r)))
      #'(lambda (tree) (and (oddp tree) tree)))
\end{verbatim}

\begin{figure}\begin{center}\begin{FramedVerb}
(defun trec (rec &optional (base #'identity))
  (labels
    ((self (tree)
           (if (atom tree)
               (if (functionp base)
                   (funcall base tree)
                   base)
               (funcall rec tree
                        #'(lambda ()
                            (self (car tree)))
                        #'(lambda ()
                            (if (cdr tree)
                                (self (cdr tree))))))))
    #'self))
\end{FramedVerb}\end{center}
\caption{ツリーに対して再帰を行うための関数．}
\label{fig:RecurOnTree2}
\end{figure}
%}}}
\subsection{いつ関数を作るべきか}  %{{{
残念なことに関数を表現するのに関数生成関数を呼ぶのは，
シャープクォート付きの$\lambda$式を呼ぶのに比べ，実行時に不必要な負荷がかかる．
シャープクォートの付いた$\lambda$式は固定されたデータだが，
生成関数の呼び出しは実行時に評価される．
本当に実行時に生成関数を呼ばなければならないなら，
それを使ってもよいことはない．
しかし，少なくともある場合には生成関数を予め呼ぶことができる．
リードマクロ\,\verb|#.|（シャープ・ドット，シャープ点）を使うと，
ソース読み込み時に新しい関数を生成できる．
その式が読み込まれたときに\verb|compose|とその引数が定義されている限り，例えば
\begin{verbatim}
(find-if #.(compose #'oddp #'truncate) lst)
\end{verbatim}
とすることができる．
これなら\verb|compose|の呼び出しはLispリーダによって評価され，
生成された関数は固定的データとしてコード内に挿入される．
\verb|oddp|と\verb|truncate|は共に組み込み関数なので，
\verb|compose|の定義が既に読み込まれている限り，
\verb|compose|の呼び出しは読み込み時に評価されると思っていいだろう．

一般的に言って，
関数の合成と組み合わせはマクロを使えば一層簡単かつ効率的に実現できる．
関数の名前空間が分離しているCommon Lispでは特に効果が顕著だ．
マクロの導入後，第15章で，ここでの話題の大半をもっと豪華な器を使って扱う．
%}}}
%}}}
\section{表現としての関数}  %{{{
一般的に言って，データ構造は何かを表現するために使われる．
配列は幾何学的変換を表現できる．
ツリーは命令のヒエラルキーを表現できる．
グラフは鉄道ネットワークを表現できる．
Lispではクロージャが表現手段に使われることがある．
クロージャ内では変数束縛は情報を蓄えることができるし，
複雑なデータ構造を構築するときのポインタの役目を果たすこともできる．
束縛を共有するかまたは互いを参照できるクロージャのグループを作ることで，
データ構造とプログラムの長所を併せ持ったハイブリッド・オブジェクトを創れる．

その内部では共有された束縛がポインタになっている．
クロージャにはポインタを高度に抽象化して扱う利点がある．
静的なデータ構造で表現する筈の物を表現するクロージャを使うことで，
しばしば優雅さと効率が大きく向上するのを期待できる．
\subsection{ネットワーク}   %{{{
クロージャには3個の便利な性質がある．
アクティブで，ローカルな状態を保持していて，複数のインスタンスを造れることだ．
アクティブでローカルな状態を持ったオブジェクトの複数のコピーを使うべき所とはどこだろう？
何よりもネットワークに関わるアプリケーションが挙げられる．
多くの場合ネットワークの節点はクロージャとして表現できる．
クロージャはそれ自身のローカルな状態を保持できるだけでなく，別のクロージャを参照できる．
だからネットワーク内の節点を表現するクロージャは，
出力を送るべき幾つかの節点（クロージャ）の状態を理解できる．
これはある種のネットワークならそのままコードに変換できるということだ．

この章と次章では，ネットワークを探索する方法を二つ検討する．
まず，構造体として定義された節点と，
ネットワークを探索する別のコードを使う伝統的な方法を追ってみる．
そして次章で，同じプログラムを単一の抽象化手法で作る方法を示す．

例として，可能な中で最も単純な応用方法を使う．
「20の質問」を行う類のあれだ．
ここで使うネットワークは二分ツリーで，葉でない節点は二択式の質問を保持し，
質問への答えに応じて右か左の部分ツリーへ下って探索して行く．
葉の節点は返り値を保持する．
探索が葉に到達すると，その値は探索結果として返される．
このプログラムの実行結果は第\ref{fig:TwentyQuestions}図に示したようになる．

\begin{figure}\begin{center}\begin{FramedVerb}
> (run-node 'people)
Is the person a man?
>> yes
Is he living?
>> no
Was he American?
>> yes
Is he on a coin?
>> yes
Is the coin a penny?
>> yes
LINCOLN
\end{FramedVerb}\end{center}
\caption{「20の質問」の実行例．}
\label{fig:TwentyQuestions}
\end{figure}

伝統的な方法は節点を表現するための何らかのデータ構造を定義することだろう．
節点は幾つかの情報を持たなければならない：それが葉であるかどうか．
そうなら返す値は何か．そうでないなら質問は何で，答えに応じてどちらへ進むか．
それを実現するのに十分なデータ構造を第\ref{fig:ReprDefNode}図に示した．
それは最小限の構造を持っている．
\verb|contents|欄は質問または返り値を保持する．
節点が葉でないなら，
\verb|yes|欄と\verb|no|欄で答えに応じてどの節点に進むかを指定する．
葉であるなら，それらが空でなのでそのことが分かる．
\verb|*nodes*|\,はグローバルなハッシュ表で，これに節点名の一覧を載せる．
最後に\verb|defnode|は新しい節点（葉であってもそうでなくてもいい）を創り，
それを\,\verb|*nodes*|\,に蓄える．
これらの素材を使ってツリーの最初の節点が定義できる：
\begin{verbatim}
(defnode 'people "Is the person a man?"
         'male 'female)
\end{verbatim}
第\ref{fig:SampleNetwork}図には，
第\ref{fig:TwentyQuestions}図のやりとりを実現するのに必要なだけのネットワークを示した．

\begin{figure}\begin{center}\begin{FramedVerb}
(defstruct node contents yes no)

(defvar *nodes* (make-hash-table))

(defun defnode (name conts &optional yes no)
  (setf (gethash name *nodes*)
        (make-node :contents conts
                   :yes yes
                   :no no)))
\end{FramedVerb}\end{center}
\caption{節点の表現と定義．}
\label{fig:ReprDefNode}
\end{figure}

\begin{figure}\begin{center}\begin{FramedVerb}
(defnode 'people "Is the person a man?" 'male 'female)
(defnode 'male "Is he living?" 'liveman 'deadman)
(defnode 'deadman "Was he American?" 'us 'them)
(defnode 'us "Is he on a coin?" 'coin 'cidence)
(defnode 'coin "Is the coin a penny?" 'penny 'coins)
(defnode 'penny 'lincoln)
\end{FramedVerb}\end{center}
\caption{ネットワークの例．}
\label{fig:SampleNetwork}
\end{figure}

そうなれば必要なのはこのネットワークを探索し，
質問を表示し，示された経路を辿る関数を書くことだけだ．
その関数\verb|run-node|は第\ref{fig:TraverseNetwork}図に示した．
名前が与えられると，対応する節点を探す．
それが葉でないなら\verb|contents|欄の質問を行い，
答えに応じて二つの可能な行き先の中から選んで探索を続ける．
節点が葉であるなら，\verb|run-node|は\verb|contents|欄の内容を返すだけだ．
この関数は第\ref{fig:SampleNetwork}図で定義されたネットワークを使い，
第\ref{fig:TwentyQuestions}図に示した出力を行う．

\begin{figure}\begin{center}\begin{FramedVerb}
(defun run-node (name)
  (let ((n (gethash name *nodes*)))
    (cond ((node-yes n)
           (format t "~A~%>> " (node-contents n))
           (case (read)
             (yes (run-node (node-yes n)))
             (t (run-node (node-no n)))))
          (t (node-contents n)))))
\end{FramedVerb}\end{center}
\caption{ネットワーク探索のための関数．}
\label{fig:TraverseNetwork}
\end{figure}
%}}}
\subsection{ネットワークのコンパイル}   %{{{
前章で書いたネットワーク・プログラムは，
どのプログラミング言語でも書けるようなものだった．
あのプログラムは全く単純なもので，他の書き方があるなどとはなかなか思えない．
しかしそれがあるのだ\wadash 実際，遥かに単純に書き直せる．

\begin{figure}\begin{center}\begin{FramedVerb}
(defvar *nodes* (make-hash-table))

(defun defnode (name conts &optional yes no)
  (setf (gethash name *nodes*)
        (if yes
            #'(lambda ()
                (format t "~A~%>> " conts)
                (case (read)
                  (yes (funcall (gethash yes *nodes*)))
                  (t (funcall (gethash no *nodes*)))))
            #'(lambda () conts))))
\end{FramedVerb}\end{center}
\caption{クロージャへとコンパイルされるネットワーク．}
\label{fig:CompiledNetwork}
\end{figure}

第\ref{fig:CompiledNetwork}図に示したコードはその点を説明している．
これがあのネットワークを機能させるのに必要な全てだ．
節点をデータ構造として表し，それを探索する別の関数を創る代わりに，
ここでは節点をクロージャとして表現した．
前の例では構造体の中に蓄えられていたデータはクロージャ内の変数束縛に蓄えられている．
節点自身の中に\verb|run-node|の機能が組み込まれているので，もうそれは必要ない．
探索を始めるには，始めたい節点で\verb|funcall|を呼ぶだけだ：
\begin{verbatim}
(funcall (gethash 'people *nodes*))
Is the person a man?
>>
\end{verbatim}
それから先の実行結果は前の実装法と全く変わりない．

節点をクロージャとして表現することで，
「20の質問」で使うネットワーク全体をコードに変換できた訳だ．
見た通り，上のコードでは実行時に名前によって節点のクロージャを探さなければならない．
しかしネットワークが実行中に再定義されることがないと分かっているなら，
更に拡張を加えられる．
節点のクロージャがハッシュ表を介さず，子を直接呼ぶようにすることができる．

\begin{figure}\begin{center}\begin{FramedVerb}
(defvar *nodes* nil)

(defun defnode (&rest args)
  (push args *nodes*)
  args)

(defun compile-net (root)
  (let ((node (assoc root *nodes*)))
    (if (null node)
        nil
        (let ((conts (second node))
              (yes (third node))
              (no (fourth node)))
          (if yes
              (let ((yes-fn (compile-net yes))
                    (no-fn (compile-net no)))
                #'(lambda ()
                    (format t "~A~%>> " conts)
                    (funcall (if (eq (read) 'yes)
                                 yes-fn
                                 no-fn))))
              #'(lambda () conts))))))
\end{FramedVerb}\end{center}
\caption{静的参照によるコンパイル．}
\label{fig:CompileWithStaticRef}
\end{figure}

第\ref{fig:CompileWithStaticRef}図には新しい定義を示した．
ここでは\,\verb|*nodes*|\,はハッシュ表ではなく捨ててもいいリストだ．
節点は前と同じく\verb|defnode|で定義するが，この時点ではクロージャは生成されない．
全ての節点の定義後，
\verb|compile-net|を呼んでネットワーク全体を一度にコンパイルする．
この関数は再帰的にツリーの葉まで下り，
戻りながら各節点で二つの部分ツリーそれぞれに対応する節点／クロージャを返す
\footnote{この実装法ではネットワークがツリーだと仮定している．
この章での実装法ではそうでなければならない．}．
だから全ての節点は二つの子の名前を把握しているだけなのではなく，
それらを直に制御できる．
\verb|compile-net|の元の呼び出しが返ると，
ネットワークのコンパイルした部分に対応する関数が得られる．
\begin{verbatim}
> (setq n (compile-net 'people))
#<Compiled-Function BF3C06>
> (funcall n)
Is the person a man?
>>
\end{verbatim}
\verb|compile-net|は二つの意味で「コンパイル」を行うことに注意しよう．
まずネットワークの抽象的表現をコードに変換するという一般的な意味のコンパイルを行う．
さらに\verb|compile-net|自身が処理系にコンパイルされていれば，
返される関数もコンパイルされたものだ．
（wowowページを参照．）

ネットワークをコンパイルした後は\verb|defnode|の作ったリストはもう要らないので，
捨ててしまって（例えば\,\verb|*nodes*|\,にnilを代入する）
ガーベジ・コレクタに任せればよい．
%}}}
\subsection{前を向く}   %{{{
ネットワークに関わる多くのプログラムが，
節点をクロージャにコンパイルすることで実装できる．
クロージャはデータ・オブジェクトであり，構造体が表現できるものを表現するのに使える．
そうするには見かけたことのない思考法が幾らか要るが，
見返りには高速で優雅なプログラムが得られる．

マクロはクロージャをデータ表現に使うときに大きな助けになる．
「クロージャで表現する」と言うのは「コンパイルする」を言い直したに過ぎない．
マクロはコンパイル時に仕事をこなすのだから，この技法にとって全く自然な手段なのだ．
マクロの導入後，第23,~24章で，
ここで使った戦略に基づいたずっと大規模なプログラムを提示する．
%}}}
%}}}
\section{マクロ}    %{{{
Lispのマクロ機能を使うと，コードの変換によってオペレータを実装することができる．
マクロ定義とは実質的にLispコードを生成する関数だ\wadash
つまりプログラムを書くプログラムだ．
この一歩から始めて，大きな可能性と予期せぬ危険に足を踏み入れていく．
第7章から第10章はマクロの基礎講座だ．
この章ではマクロがどのように動作するのかを説明し，
マクロを書いたり動作を確かめるときのテクニックを示し，
マクロを書くスタイルについての話題に進む．
\subsection{マクロはどのように動作するか}   %{{{
マクロは呼び出せるし値を返せるので，関数と一緒くたにされがちだ．
マクロ定義は関数定義に似ていることもあるし，
実際はマクロである\verb|do|を普段「組み込み関数」と呼ぶ人も多い．
しかしこの喩えを突き詰めすぎると混乱の元になる．
マクロの動作は普通の関数とは違っている．
マクロはどのように，そしてなぜ違うのかを知ることは，マクロを正しく使うための鍵だ．
関数は\emph{結果}を生むが，マクロは\emph{式}を生む\wadash
そしてこの式が評価されると結果を生む．

習い始めるのに一番良い方法は，実例に当たることだ．
ここでは引数をnilに設定するマクロ\verb|nil!|を書きたいとしよう．
\verb|(nil!  x)|としたとき\verb|(setq x nil)|と同じ効果が欲しいのだ．
それには\verb|nil!|を，ある形を持った式を別の形の式に変えるマクロとして定義する．
\begin{verbatim}
> (defmacro nil! (var)
    (list 'setq var nil))
NIL!
\end{verbatim}
人間語に直せば，この定義はLispに
「\verb|(nil! var)|の形の式を見たら，
必ず評価前に\verb|(setq var nil)|の形に変えること．」
と命じている．

マクロの生成した式は元のマクロ呼び出しの場所で評価される．
マクロ呼び出しとは第1要素がマクロの名前であるリストだ．
マクロ呼び出し\verb|(nil!  x)|をトップレベルに打ち込んだら何が起きるだろうか？
Lispは\verb|nil!|がマクロの名前であることに気付き，
\begin{enumerate}
\item 与えた定義の指定した式を生成し，
\item その式を元のマクロ呼び出しの場所で評価する．
\end{enumerate}

新しい式を生成する工程はマクロ展開と呼ばれる．
Lispは\verb|nil!|の定義を探すが，
そこにはマクロ呼び出しを置き換える式の生成法が載っている．
\verb|nil!|の定義が，
マクロ呼び出しの引数として与えられた式に対して関数のように適用される．
それは3個の要素（\verb|setq|，マクロに引数として与えられた式，nil）
から成るリストを返す．
この場合\verb|nil!|の引数は\verb|x|だから，マクロ展開の結果は\verb|(setq x nil)|だ．

マクロ展開の後，第2工程すなわち評価が行われる．
Lispは展開結果\verb|(setq x nil)|を，始めの場所に直接書いてあったかのように評価する．
必ずしもトップレベルのときのように評価が展開直後に行われる訳ではない．
関数定義内のマクロ呼び出しは関数がコンパイルされたときに展開されるが，
展開形（またはそれに基づくオブジェクト・コード）は
その関数が呼び出されるまで評価されない．

マクロに関して出会う問題の多くは，
マクロ展開と評価をきちんと区別することで避けられる．
マクロを書くときは，展開時と評価時に，
それぞれどのような動作をするのかしっかり理解すること．
なぜなら二つの工程は一般的に別の種類のオブジェクトに対して作用するからだ：
マクロ展開は式を扱い，評価はその値を扱う．

マクロ展開は\verb|nil!|の場合より複雑になることがある．
\verb|nil!|の展開形は組み込み特殊オペレータの呼び出しだったが，
展開形が別のマクロ呼び出しになることもある．
ちょうどロシア人形の中に別の人形が入っているようなものだ．
そのようなとき，マクロ展開はマクロ呼び出しでない式に到達するまで続く．
この過程が最終的に終わるまでには，任意の長さの段階を要する．

多くのプログラミング言語は何らかの種類のマクロを備えているが，
Lispのマクロは並外れて強力だ．
Lispコードのファイルがコンパイルされるとき，
パーサがソースを読んで出力をコンパイラに送る．
大事なのは次だ．
パーサの出力はLispのオブジェクトのリストから成る．
マクロを使えば，
プログラムがパーサとコンパイラの間の中間形式のときに操作することができる．
必要ならばその操作でLispの拡張も行える．
展開形を生み出すマクロはLispの力の全てを握っている．
それはマクロが生まれ持った性質だ．
実際，マクロはLispの関数だ\wadash たまたま式を返すだけのことだ．
\verb|nil!|の定義では\verb|list|が使われただけだったが，
別のマクロでは展開時に大きなサブルーチンを呼び出すこともある．

コンパイラが読む情報を書き換えられるというのは
コンパイラを書き換えられるのとほとんど同じだ．
既存のデータ構造を変形することで定義できるようなデータ構造なら何でもLispに追加できる．
%}}}
\subsection{逆クォート}   %{{{
逆クォート（バッククォート，backquote）は特別なクォートで，
Lispの式の雛形を作るのに使える．
それが一番よく使われるのはマクロ定義の中だ．

逆クォート\,\verb|`|\,は，普通のクォート\,\verb|'|を逆さにした形なのでそう呼ばれる．
逆クォートが式の前に付いているだけのときは，働きはクォートと変わらない：
\begin{center}
\verb|`(a b c)|は\,\verb|'(a b c)|と等価である．
\end{center}

逆クォートが便利なのは，
カンマ\,\verb|,|やカンマ・アット\,\verb|,@|\,と組み合わせて使うときだ．
逆クォートがリストの雛形になるとき，カンマはその中に値を挿入する．
逆クォート付きリストは，各要素にクォートを付けて\verb|list|を呼ぶのと等価だ．
つまり
\begin{center}
\verb|`(a b c)|は\verb|(list 'a 'b 'c)|と等価である．
\end{center}
逆クォートのスコープ内では，カンマはLispに「評価の保護を止めろ」と命じる．
カンマがリストのある要素の前に付くと，
そこに仮想的に付けられているクォートの効果を打ち消す．
だから
\begin{center}
\verb|`(a ,b c ,d)|は\verb|(list 'a b 'c d)|と等価である．
\end{center}
シンボル\verb|b|の代わりにその値が挿入されたリストが作られる．
どれ程深く入れ子になったリスト内でもカンマは機能する：
\begin{verbatim}
> (setq a 1 b 2 c 3)
3
> `(a ,b c)
(A 2 C)
> `(a (,b c))
(A (2 C))
\end{verbatim}
またカンマの前にクォートが付いてもよいし，クォート付きの部分リスト内で使ってもよい：
\begin{verbatim}
> `(a b ,c (',(+ a b c)) (+ a b) 'c '((,a ,b)))
(A B 3 ('6) (+ A B) 'C '((1 2)))
\end{verbatim}

1個のカンマは1個の逆クォートの効果を打ち消すのだから，
カンマは逆クォートと対応が取れなければならない．
ある特定のオペレータがカンマの前に付くか，カンマを含む式の前に付いているとき，
「カンマはそのオペレータに囲まれている」と言うことにしよう．
例えば\verb|`(,a ,(b `,c)))|では，最後のカンマはカンマ1個と逆クォート2個に囲まれている．
一般的に言うと：$n$個のカンマに囲まれたカンマは
最低$n+1$個の逆クォートに囲まれていなければならない．
それから明らかに分かるのは，
カンマは逆クォートの付いた式の外側にあってはならないということだ．
逆クォートとカンマは，上の規則に従う限り入れ子になってもよい．
次の式はトップレベルに打ち込んだらどれもエラーになる：
\begin{verbatim}
,x   `(a ,,b c)   `(a ,(b ,c) d)   `(,,`a)
\end{verbatim}
逆クォートの中の逆クォートは，マクロを定義するマクロ位でしか使われない．
どちらの点についても第16章で議論する．

逆クォートは大抵リストを作るのに使われる
\footnote{逆クォートはベクタを作るのにも使えるが，
マクロ定義内では滅多にそういうことはしない．}．
逆クォートの作るリストは\verb|list|と普通のクォートを使って作ることもできる．
逆クォートを使うことの利点は，
逆クォート付きの式はそれの生成する式と似ているので式を読み易くできることだ．
前章で\verb|nil!|を次のように定義した：
\begin{verbatim}
(defmacro nil! (var)
  (list 'setq var nil))
\end{verbatim}
逆クォートを使うと，同じマクロが次のように定義できる：
\begin{verbatim}
(defmacro nil! (var)
  `(setq ,var nil))
\end{verbatim}
この場合では違いはあまりないが，
マクロ定義が長くなれば逆クォートを使う重要性は増す．
第\ref{fig:Backquote}には，
数の符号について\verb|if|分岐を行うマクロ\verb|nif|の定義の候補を二つ示した
\footnote{このマクロ定義はgensymの使用を避けるために変なやり方をしている．
よい定義方法はzipページで示す．}．

第1引数は評価されると数にならなければならない．
そしてその数か正か$0$か負かに応じてそれぞれ第2，3，4引数が評価される：
\begin{verbatim}
> (mapcar #'(lambda (x)
              (nif x 'p 'z 'n))
          '(0 2.5 -8))
(Z P N)
\end{verbatim}

\begin{figure}\begin{center}
\fbox{~\,\begin{minipage}{\FrameWidth}\narrowbaselines
\vspace{3pt}\hspace{4zw}逆クォートを使う：
\begin{center}\begin{minipage}{240pt}\texttt{%
(defmacro nif (expr pos zero neg)\\
~~`(case (truncate (signum ,expr))\\
~~~~~(1 ,pos)\\
~~~~~(0 ,zero)\\
~~~~~(-1 ,neg)))
}\end{minipage}\end{center}
\hspace{4zw}逆クォートを使わない：
\begin{center}\begin{minipage}{240pt}\texttt{%
(defmacro nif (expr pos zero neg)\\
~~(list 'case\\
~~~~~~~~(list 'truncate (list 'signum expr))\\
~~~~~~~~(list 1 pos)\\
~~~~~~~~(list 0 zero)\\
~~~~~~~~(list -1 neg)))
}\end{minipage}\end{center}
\vspace{1.3em}\end{minipage}~\,}\end{center}
\caption{マクロ定義に逆クォートを使った例と使わない例．}
\label{fig:Backquote}
\end{figure}

第\ref{fig:Backquote}図の二つのマクロ定義は同じマクロを定義している．
ただ1番目は逆クォートを使っているが，
2番目では\verb|list|を陽に呼ぶことで展開形を作っている．
最初の定義からは，例えば\verb|(nif x 'p 'z 'n)|が
\begin{verbatim}
(case (truncate (signum x))
  (1 'p)
  (0 'z)
  (-1 'n))
\end{verbatim}
に展開されるのはすぐ分かる．
マクロ定義本体の形が，生成される展開形にそっくりだからだ．
逆クォートのない2番目の定義を理解するには，
展開の過程を頭の中で追っていかなければならない．

カンマ・アット\,\verb|,@|\,はカンマの変種で，機能はカンマと同じだが違いが1点ある：
次に続く式の値をカンマのようにそのまま挿入するのでなく，
カンマ・アットは切り張り操作を行う．
つまり1番外側の括弧を取り除いて挿入する：
\begin{verbatim}
> (setq b '(1 2 3))
(1 2 3)
> `(a ,b c)
(A (1 2 3) C)
> `(a ,@b c)
(A 1 2 3 C)
\end{verbatim}
カンマはリスト\verb|(1 2 3)|を\verb|b|の所に挿入するが，
カンマ・アットはそこにリストの要素を挿入する．
カンマ・アットを使うには幾つか制限がある：
\begin{enumerate}
\item 引数に切り張り操作を行うので，カンマ・アットは連続構造内になければならない．
    \verb|`,@b|等とするのは誤りだ．
    \verb|b|の値を張り付ける先がないからだ．
\item 切り張りされるオブジェクトは，最後に来ない限りリストでなければならない．
    式\,\verb|`(a ,@1)|が評価されると\verb|(a . 1)|となるが，
    \verb|`(a ,@1 b)|等として，
    アトムをリストの中に切り張りしようとするとエラーになる．
\end{enumerate}

カンマ・アットが使われるのは，
不定個の引数を取り，やはり不定個の引数を取る関数やマクロに渡すマクロの中が多い．
普通この状況は暗黙のブロックを実装するときに現れる．
Common Lispには\verb|block|，\verb|tagbody|，\verb|progn|等，
コードをブロックにまとめるオペレータが幾つかある．
これらのオペレータはソース・コード内には滅多に出て来ない．
それらは暗黙に使われる\wadash つまり，マクロに隠されている．

暗黙のブロックは式を実行本体として持てる組み込みマクロでは必ず使われている．
例えば\verb|let|と\verb|cond|には暗黙の\verb|progn|が使われている．
そんな中で最も単純な組み込みマクロは\verb|when|だろう：
\begin{verbatim}
(when (eligible obj)
  (do-this)
  (do-that)
  obj)
\end{verbatim}
\verb|(eligible obj)|が真を返すとき残りの式が評価され，
\verb|when|が式として返す値はそのうち最後の式の値だ．
コンマ・アットを使った例として，ここに\verb|when|の定義方法の一例を示す：
\begin{verbatim}
(defmacro our-when (test &body body)
  `(if ,test
       (progn
         ,@body)))
\end{verbatim}
この定義は\,\verb|&body|仮引数を使っているが，
これは表示整形(pretty-printing)の効果を除いて\,\verb|&rest|と同じで，
任意個の引数が取れるようにしている．
またそれらを式\verb|progn|の中に切り張りするためにカンマ・アットを使っている．
上の呼び出しでの展開形では，本体の3個の式は1個の\verb|progn|の中に現れる：
\begin{verbatim}
(if (eligible obj)
    (progn (do-this)
           (do-that)
           obj))
\end{verbatim}
繰り返しを行うマクロの大半は似た方法で引数を切り張りする．

カンマ・アットの効果は逆クォートを使わなくても実現できる．
例えば式\,\verb|`(a ,@b c)|は\verb|(cons 'a|  \verb|(append b|  \verb|(list 'c)))|と等価だ．
カンマ・アットの存在理由は上のように式を生成する式を読み易くすることだけだ．

マクロ定義は（普通）リストを生成する．
マクロ展開は関数リストを使っても作れるが，
逆クォートを使ったリストの雛形は仕事を随分楽にしてくれる．
\verb|defmacro|と逆クォートで定義したマクロは，
表面的には\verb|defun|で定義した関数に似ている．
この類似性にミスリードされない限り，
逆クォートによってマクロを書くのも読むのも楽になる．

逆クォートはマクロ定義の中で非常によく使われるので，
\verb|defmacro|の一部だと思っている人もいる．
逆クォートについて忘れてはいけないことの最後は，
それがマクロ内での役割とは別に自分自身の生き方があるということだ．
連続構造を生成する必要のあるときには，いつでも逆クォートが使える：
\begin{verbatim}
(defun greet (name)
  `(hello ,name))
\end{verbatim}
%}}}
\subsection{単純なマクロの定義}   %{{{
プログラミングの学習では，
できるだけ早く実験することが一番の方法であることが多い．
理論的に完全に理解するのは後でもいい．
それに従って，この章ではマクロをすぐに書き始める方法を提示する．
その方法が使える範囲は広くはないが，可能なところでは機械的に適用できる．
（もうマクロを書いた経験があるのなら，この章は飛ばしてもよい．）

例としてCommon Lispの組み込み関数\verb|member|の変種を書く方法について考える．
普通\verb|member|は2個のオブジェクトが等しいかどうか調べるのに\verb|eql|を使う．
\verb|eq|を使って所属関係を調べたいときには，わざわざ指定しなければならない：
\begin{verbatim}
(member x choices :test #'eq)
\end{verbatim}
これを何度も繰り返すことがあるなら，
必ず\verb|eq|を使う\verb|member|の変種を書いてもいいだろう．
幾つかの昔のLisp方言にはそんな関数があり，\verb|memq|と呼ばれていた：
\begin{verbatim}
(memq x choices)
\end{verbatim}
普通\verb|memq|はインライン関数として定義されるが，
マクロの例を示すため，ここではマクロとして復活させる．

\begin{figure}\begin{center}
\fbox{~\,\begin{minipage}{\FrameWidth}\begin{center}
\vspace*{3pt}呼び出し：\texttt{(memq x choices)}\\[3pt]
その展開形：\texttt{(member x choices :test \#'eq)}%
\begin{picture}(1,1)
\put(-106,6){\line(3,2){16}}
\put(-76,6){\line(3,2){16}}
\end{picture}
\end{center}\vspace{1.3em}\end{minipage}~\,}\end{center}
\caption{\texttt{memq}を書くのに使われた線図．}
\label{fig:DiagramMemq}
\end{figure}

さて方法とは：
まず定義したいマクロの典型的な呼び出し方から始める．
メモ用紙にそれを書き，その下にそれが展開されてできる筈の式を書く．
第\ref{fig:DiagramMemq}図にそのような2個の式の例を示した．
マクロ呼び出しに従い，これから書くマクロの仮引数リストを作る．
引数それぞれについて適当な仮引数名を考える．
この場合引数が2個あるので仮引数を2個使う．
それらを\verb|obj|と\verb|lst|と呼ぼう：
\begin{verbatim}
(defmacro memq (obj lst)
\end{verbatim}
そして先程書いた2個の式に戻る．
マクロ呼び出しの中の引数それぞれから，
下の展開形の中で使われている場所まで線を引く．
第\ref{fig:DiagramMemq}図には平行な2本の線が引いてある．
マクロ本体を書くには展開形に注意を向けなければいけない．
まず逆クォートから本体を書き始める．
次に展開形を式毎に区切って読んでいく．
マクロ呼び出しの引数の一部でない括弧を見つけたら，マクロ定義内にも括弧を書く．
すると逆クォートの次には左括弧が来る．
そうしたら展開形の式それぞれについて
\begin{enumerate}
\item マクロ呼び出しと線でつながってなければ，その式そのものを書く．
\item マクロ呼び出しの引数の一つとつながっていれば，
    マクロの仮引数リスト内で対応するシンボルを書き，その前にカンマを付ける．
\end{enumerate}
第1要素\verb|member|はどこにもつながっていないので，
\verb|member|そのものを使う：
\begin{verbatim}
(defmacro memq (obj lst)
  `(member
\end{verbatim}
しかし\verb|x|からは元の式の第1引数に線が引いてあるので，
マクロ本体の中にカンマを付けた第1引数を置く：
\begin{verbatim}
(defmacro memq (obj lst)
  `(member ,obj
\end{verbatim}
この要領で続けていくと次のようなマクロ定義が完成する：
\begin{verbatim}
(defmacro memq (obj lst)
  `(member ,obj ,lst :test #'eq))
\end{verbatim}

これまでのところ，決まった数の引数を取るマクロだけを書いてきた．
さて今書きたいのは\verb|while|だとしよう．
これはテスト式と本体となる幾らかの式を引数に取り，
テスト式が真を返す限りその式を繰り返し実行する．
第\ref{fig:DiagramWhile}図に猫の振る舞いを描写した\verb|while|ループの例を示した．

\begin{figure}\begin{center}
\fbox{~\,\begin{minipage}{\FrameWidth}\begin{center}
\vspace*{3pt}\begin{minipage}{120pt}\narrowbaselines
\texttt{(while hungry\\
~~(stare-intently)\\
~~(meow)\\
~~(rub-against-legs))}\\
\begin{picture}(1,1)% 行送りは12ptになってる
\put(69,50){\line(1,0){26}}
\put(95,14){\oval(40,72)[r]}
\put(95,-22){\line(-1,0){21}}
\put(15,26){\line(-1,0){10}}% ここから左
\put(15,26){\oval(22,24)[l]}
\put(5,-10){\oval(40,72)[l]}
\put(15,-46){\oval(22,24)[l]}
\put(5,-46){\line(1,0){10}}
\end{picture}\\
\texttt{(do ()\\
~~((not hungry))\\
~~(stare-intently)\\
~~(meow)\\
~~(rub-against-legs))}
\end{minipage}
\end{center}\vspace{1.3em}\end{minipage}~\,}\end{center}
\caption{\texttt{while}を書くのに使われた線図．}
\label{fig:DiagramWhile}
\end{figure}

そのようなマクロを書くには，先程の方法を少し修正する必要がある．
まず前と同じようにマクロ呼び出しの例を書くことから始める．
それからマクロの仮引数リストを書くのだが，
任意個の引数を取りたいところでは
\,\verb|&rest|または\,\verb|&body|の次に仮引数を置く：
\begin{verbatim}
(defmacro while (test &body body)
\end{verbatim}
さて展開される筈の形をマクロ呼び出しの下に書き，
前と同じようにマクロ呼び出しの引数を展開形内の場所までつなぐ線を引こう．
しかし幾つかの引数が
単一の\verb|&rest|または\verb|&body|仮引数として詰め込まれるときは，
それらを塊として扱い，引く線はそれら全体に対して1本にする．
結果の線図は第\ref{fig:DiagramWhile}図に示した．

そしてマクロ定義の本体を書くには展開形を参考に前と同じことをするが，
先程の2個に加えもう1個の規則が必要だ：
\begin{enumerate}
\setcounter{enumi}{2}
\item 展開形内の幾つかの式からマクロ呼び出し内の幾つかの引数へつながる線があれば，
    対応する\,\verb|&rest|（または\,\verb|&body|）仮引数を書き，
    その前にカンマ・アットを置く．
\end{enumerate}
結局マクロ定義は以下のようになる：
\begin{verbatim}
(defmacro while (test &body body)
  `(do ()
     ((not ,test))
     ,@body))
\end{verbatim}
式を本体として持つマクロを書くには，幾つかの仮引数が漏斗として働く必要がある．
ここではマクロ呼び出し内の複数の引数が本体にまとめられ，
本体が展開形の中に切り張りされるときに再び分解されている．

この章で説明した手法を使えば，最も単純なマクロ\wadash
仮引数を並び替えるだけのもの\wadash を書くことができる．
しかしマクロの力はそんなものではない．
第7.7節では，展開形がただの逆クォート付きリストでは表現できないような例を示す．
そういうマクロを展開するにはマクロ自身がプログラムでなければならない．
%}}}
\subsection{マクロ展開の確認}   %{{{
マクロを書くのが終わったら，どうやってその動作を確かめよう？
\verb|memq|のようなマクロは単純だから，ちょっと見ればその動作が分かる．
更に複雑なマクロを書くときは，それが正しく展開されるのか確認できなければならない．

\begin{figure}\begin{center}\begin{FramedVerb}
> (defmacro while (test &body body)
    `(do ()
       ((not ,test))
       ,@body))
WHILE
> (pprint (macroexpand '(while (able) (laugh))))
(BLOCK NIL
       (LET NIL
            (TAGBODY
              #:G61
              (IF (NOT (ABLE)) (RETURN NIL))
              (LAUGH)
              (GO #:G61))))
T
> (pprint (macroexpand-1 '(while (able) (laugh))))
(DO NIL
    ((NOT (ABLE)))
    (LAUGH))
T
\end{FramedVerb}\end{center}
\caption{1個のマクロとその2段階の展開．}
\label{fig:Macroexpand}
\end{figure}

第\ref{fig:Macroexpand}図には，1個のマクロ定義とその2通りの展開形を示した．
組み込み関数\verb|macroexpand|は指揮を引数に取り，それをマクロ展開したものを返す．
マクロ呼び出しを\verb|macroexpand|に渡すと，
それが評価前に最終的にどのように展開されるのかが分かる．
しかし完全な展開形はマクロの確認では必ずしも望ましいものではない．
問題のマクロが別のマクロを使っていると展開が進みすぎてしまうので，
完全な展開形は読みづらいことがある．

第\ref{fig:Macroexpand}図の1番目の式からは，
\verb|while|が意図した通りに展開されたかどうかは判断し辛い．
組み込みマクロの\verb|do|が\verb|prog|に展開され，さらにそれも展開されているからだ．
ここで必要なのは1段階だけ展開した結果を見る方法だ．
それが2番目の例に示した組み込み関数\verb|macroexpand-1|の目的だ．
\verb|macroexpand-1|は1段階だけマクロを展開すると，
それが依然としてマクロ呼び出しであっても動作を止める．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro mac (expr)
  `(pprint (macroexpand-1 ',expr)))
\end{FramedVerb}\end{center}
\caption{マクロ展開確認用のマクロ．}
\label{fig:TestExpand}
\end{figure}

マクロ呼び出しの展開形を見たいとき，いつも
\begin{verbatim}
(pprint (macroexpand-1 '(or x y)))
\end{verbatim}
と打ち込むのは馬鹿らしい．
第\ref{fig:TestExpand}図の新しいマクロを使うなら，代わりにこうすればよい：
\begin{verbatim}
(mac (or x y))
\end{verbatim}

デバッグを進めるときの定石は，関数は呼び出すこと，マクロは展開することだ．
しかしマクロ呼び出しは2層に渡る命令が関わるので，誤りの起きる場所も2箇所ある．
マクロの動作がおかしいときは，大抵は展開形を見るだけで間違いが見つかる．
しかし，希に展開形には問題ないように見えて，
問題がどこで起きるのかを見るためにそれを評価したいときもある．
展開形にフリー変数が含まれるときは，先にそれらを設定したいこともあるだろう．
処理系によっては，展開形をコピーしてトップレベルに貼り付けたり，
展開形を選択してメニューから\verb|eval|を選んで評価させることができる．
どうしても問題が掴めないときは，適当な変数を\verb|macroexpand-1|の返すリストに設定し，
それに対して\verb|eval|を呼ぶこと：
\begin{verbatim}
> (setq exp (macroexpand-1 '(memq 'a '(a b c))))
(MEMBER (QUOTE A) (QUOTE (A B C)) :TEST (FUNCTION EQ))
> (eval exp)
(A B C)
\end{verbatim}

最後に，マクロ展開は単なるデバッグの補助手段ではなく，
マクロの書き方の勉強手段でもあることを言っておきたい．
Common Lispには100以上の組み込みマクロがあり，中には大変複雑なものもある．
そんなマクロの展開形を見ることで，それらがどう書かれたのかが分かることも多い．
%}}}
\subsection{引数リストの構造化代入}   %{{{
構造化代入(destructuring)とは，関数呼び出しによって行われる一種の代入
\footnote{構造化代入は大抵，代入を行うのでなく束縛を作るオペレータで見られる．
しかし概念的には構造化代入は値の代入の一手法であって，
新しい変数だけでなく既存の変数に対しても機能する．
つまり構造化代入型\texttt{setq}を書いて悪いことはない．}の一般化だ．
幾つかの引数を取る関数を定義したとき
\begin{verbatim}
(defun foo (x y z)
  (+ x y z))
\end{verbatim}
その関数が呼ばれると
\begin{verbatim}
(foo 1 2 3)
\end{verbatim}
関数の仮引数には順番に従って引数が代入される：
\verb|x|には1，\verb|y|には2，そして\verb|z|には3という風に．
構造化代入とは，このような引数の場所に従って行われる代入が，
任意のリスト構造に対して\verb|(x y z)|と同様に行われることだ．

Common Lispのマクロ\verb|destructuring-bind|（\textsf{CLtL2}で新しく導入された）は，
パターン，リストに評価される引数及び本体となる式を引数に取り，
パターン内の仮引数をリスト内の対応する要素に束縛した状態で式を評価する：
\begin{verbatim}
> (destructuring-bind (x (y) . z) '(a (b) c d)
    (list x y z))
(A B (C D))
\end{verbatim}
この新オペレータとその仲間が第18章の主題になる．

構造化代入はマクロの仮引数リストでも使える．
Common Lispの\verb|defmacro|では仮引数リストは任意のリスト構造であってよい．
マクロ呼び出しが展開されたとき，
マクロ呼び出しのcomponentsはマクロの仮引数に
\verb|destructuring-bind|と同様に代入される．
組み込みマクロ\verb|dolist|は仮引数リストの構造化代入を活用している．
次のようなマクロ呼び出しでは：
\begin{verbatim}
(dolist (x '(a b c))
  (print x))
\end{verbatim}
展開されて生まれる関数は，第1引数として与えられたリストの中から
\verb|x|と\verb|'(a b c)|を取り出さなければならない．
それは\verb|dolist|に適切な仮引数リストを与えることで暗黙の中に実現された
\footnote{後に導入するgensymの使用を避けるため，
ここではおかしな方法で定義している．}：
\begin{verbatim}
(defmacro our-dolist ((var list &optional result) &body body)
  `(progn
     (mapc #'(lambda (,var) ,@body)
           ,list)
     (let ((,var nil))
       ,result)))
\end{verbatim}
Common Lispでは，普通\verb|dolist|のようなマクロは
実行本体でない引数をリスト内にまとめ込んでいる．
\verb|dolist|はそれが返す結果になる付加的な引数を取るので，
何にせよ1種類目の引数を独立したリストにまとめなれけばならない．
しかし余分なリスト構造が必要でなくても，
それによって\verb|dolist|の呼び出しが読み易くなる．
ここで\verb|when|に似たマクロ\verb|when-bind|を定義したいとしよう．
ただしこれは調べる式の返す値に何かの変数を束縛するものとする．
このマクロは入れ子になった仮引数リストを使うと一番上手く実装できるだろう：
\begin{verbatim}
(defmacro when-bind ((var expr) &body body)
  `(let ((,var ,expr))
     (when ,var
       ,@body)))
\end{verbatim}
これは次のように呼び出せばよく，
\begin{verbatim}
(when-bind (input (get-user-input))
           (process input))
\end{verbatim}
こうしなくてもいい：
\begin{verbatim}
(let ((input (get-user-input)))
  (when input
    (process input)))
\end{verbatim}
Used sparingly,
仮引数リストの構造化代入は明確なコードにつながる．
少なくとも，
2個以上の引数と本体となる式を取る\verb|when-bind|や\verb|dolist|等のマクロで使える．
%}}}
\subsection{マクロのモデル}   %{{{
マクロが何をするのかを形式的に説明しても，長く，ややこしくなるだけだろう．
経験を積んだLispプログラマの頭の中にもそんな説明がある訳ではない．
\verb|defmacro|の定義方法を想像することで，それが何をするのかを覚えた方が便利だ．

Lispにはそのような説明を使う長い伝統がある．
1962年初版の\emph{The Lisp 1.5 Programmer's Manual}\note{Lisp1.5}も，
参考のためにLispで書かれた\verb|eval|の定義を載せている．
\verb|defmacro|自身がマクロなので，同じ扱いができる．
定義は第\ref{fig:SketchDefmacro}図に示した．
そこではまだ扱っていない技法を幾つか使っているので，
参考にするのは後にしたいと思われる方もいるだろう．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro our-expander (name) `(get ,name 'expander))

(defmacro our-defmacro (name parms &body body)
  (let ((g (gensym)))
    `(progn
       (setf (our-expander ',name)
             #'(lambda (,g)
                 (block ,name
                        (destructuring-bind ,parms (cdr ,g)
                          ,@body))))
       ',name)))

(defun our-macroexpand-1 (expr)
  (if (and (consp expr) (our-expander (car expr)))
      (funcall (our-expander (car expr)) expr)
      expr))
\end{FramedVerb}\end{center}
\caption{\texttt{defmacro}の概形．}
\label{fig:SketchDefmacro}
\end{figure}

第\ref{fig:SketchDefmacro}図に示した定義は，
マクロが何をするのかについてかなり正確な感覚を与えてくれるが，
飽くまでも概形なので不完全な所もある．
これは\,\verb|&whole|キーワードを適切に扱えない．
また\verb|defmacro|が第1引数にマクロ関数として実際に保持させるものは2引数の関数で，
マクロ呼び出しと，それが呼び出されたレキシカル環境を引数に取る．
しかしそれらの性質が使われるのは最高度に難解なマクロだけだ．
マクロが第\ref{fig:SketchDefmacro}図のように実装されていると思っていれば，
間違うことはまず無いだろう．
例えばこの本の中で定義されたマクロはそれを使っても全て正しく機能する．

第\ref{fig:SketchDefmacro}図の定義が生み出す展開形の関数は，
シャープクォート付きの$\lambda$式だ．
つまりそれはクロージャである筈だ．
マクロ定義内のどんなフリーシンボルも
\verb|defmacro|の呼び出された環境内の変数を参照できる．
だから次のようにすることができる筈だ：
\begin{verbatim}
(let ((op 'setq))
  (defmacro our-setq (var val)
    (list op var val)))
\end{verbatim}
\textsf{CLtL2}では，確かに可能だ．
しかし\textsf{CLtL1}では，マクロ展開関数は空レキシカル環境で定義されていたので
\footnote{この区別が問題になるマクロの例については，第pomページの注を参照．}，
古い処理系では上の\verb|our-setq|は動作しないかもしれない．
%}}}
\subsection{プログラムとしてのマクロ}   %{{{
マクロ定義は必ずしも単なる逆クォート付きリストでなくてもよい．
マクロはある種の式を別の形に変形する関数だ．
その関数は結果を生成するために\verb|list|を呼んでもいいが，
数百行のコードから成る副プログラムを丸ごと呼んでもいい．

第7.3節では，マクロを簡単に書く方法を示した．
その方法によって，展開形がマクロ呼び出しの中と同じ式を含むマクロを書くことができる．
しかし残念なことに，その条件を満たすのは一番単純な種類のマクロだけだ．
複雑なマクロの例として，組み込みマクロ\verb|do|について考えてみよう．
\verb|do|は引数を並び替えるだけのマクロとして定義することは不可能だ．
その展開時には，マクロ呼び出しには決して出て来ない複雑な式を生成しなければならない．

マクロを書くときの更に一般的な手法とは，
使えるようにしたい式の種類と，それがどのように展開されるかについて考え，
使いたい式を展開形に変形するプログラムを書くことだ．
マクロの例を手で展開してみて，
ある形が変形されるときには何が起きているのかを見ると良い．
例に倣うことで，自分の求めるマクロには何が必要なのかを掴むことができる．

\begin{figure}\begin{center}
\fbox{~\,\begin{minipage}{\FrameWidth}\begin{center}
\begin{minipage}{210pt}\vspace*{4pt}\narrowbaselines
\texttt{(do ((w 3)\\
~~~~~(x 1 (1+ x))\\
~~~~~(y 2 (1+ y))\\
~~~~~(z))\\
~~((> x 10) (princ z) y)\\
~~(princ x)\\
~~(princ y))}\\[4pt]
これは次のようなものに展開されて欲しい：\\
\texttt{(prog ((w 3) (x 1) (y 2) (z nil))\\
~~~~~~foo\\
~~~~~~(if (> x 10)\\
~~~~~~~~~~(return (progn (princ z) y)))\\
~~~~~~(princ x)\\
~~~~~~(princ y)\\
~~~~~~(psetq x (1+ x) y (1+ y))\\
~~~~~~(go foo))}
\end{minipage}
\end{center}\vspace{1.3em}\end{minipage}~\,}\end{center}
\caption{\texttt{do}の望ましい展開方法．}
\label{fig:DesiredExpansionDo}
\end{figure}

第\ref{fig:DesiredExpansionDo}図に示したのは，\verb|do|の使用例と，
それが展開されて生まれる筈の式だ．
自分の手で展開してみるのはマクロがどのように働くべきかを明確にするのに良い方法だ．
例えば，展開形を手で書かないと，
ローカル変数の更新に\verb|psetq|を使わなければならないことは明らかではないだろう．

組み込みマクロ\verb|psetq|（``parallel \verb|setq|''つまり「並列\verb|setq|」）
の動作は\verb|setq|と似ているが，
全ての（偶数番目の）引数がどの代入よりも前に評価される点が違う．
普通の\verb|setq|が2個より多い引数を取るとき，
第1引数の新しい値は第4引数の評価中に見えている：
\begin{verbatim}
> (let ((a 1))
    (setq a 2 b a)
    (list a b))
(2 2)
\end{verbatim}
ここでは\verb|a|が最初に設定されたので，\verb|b|は\verb|a|の新しい値の2を得た．
\verb|psetq|はその引数が並列的に代入されたかのように機能するものだ：
\begin{verbatim}
> (let ((a 1))
(psetq a 2 b a)
(list a b))
(2 1)
\end{verbatim}
そのため，ここでは\verb|b|は\verb|a|の古い値を得ている．
マクロ\verb|psetq|は，\verb|do|等，
引数の幾つかを並列的に評価する必要のあるマクロの補助のために特に提供されたものだ．
（\verb|setq|を使っていたら，\verb|do*|\,の定義になっていた．）

展開形を見れば，\verb|foo|をループ用ラベルに使うのは本当はまずいことも明らかだ．
\verb|foo|が\verb|do|の実行本体のループ用ラベルに使われていたらどうするのか？
第9章で，この問題を詳細に取り扱う：
今の所は，マクロ展開では\verb|foo|ではなく，
関数\verb|gensym|の返す特別な無名シンボルを使わなければならない，と覚えておけばよい．

\verb|do|を書くには，第\ref{fig:DesiredExpansionDo}図の上の式を
下の形に変形するには何が必要かを考えることになる．
そのような変形を行うには，
逆クォート付きリストの正しい位置にマクロの仮引数を入れるだけでは済まない．
先頭の\verb|prog|の次のリストはシンボルとその初期値から成るが，
それらは\verb|do|の第2引数の中から抽出しなければならない．
第\ref{fig:ImplementDo}図の\verb|make-initforms|はそんなリストを返す．
それから\verb|psetq|のために引数のリストを作らなければならないが，
更新すべきシンボルは全部ではないので，こちらの処理は複雑になる．
第\ref{fig:ImplementDo}図の\verb|make-stepforms|は，\verb|psetq|に渡す引数を返す．
これら2個の関数を使うと，残りの定義には込み入った技は要らない．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro our-do (bindforms (test &rest result) &body body)
  (let ((label (gensym)))
    `(prog ,(make-initforms bindforms)
           ,label
           (if ,test
               (return (progn ,@result)))
           ,@body
           (psetq ,@(make-stepforms bindforms))
           (go ,label))))

(defun make-initforms (bindforms)
  (mapcar #'(lambda (b)
              (if (consp b)
                  (list (car b) (cadr b))
                  (list b nil)))
          bindforms))

(defun make-stepforms (bindforms)
  (mapcan #'(lambda (b)
              (if (and (consp b) (third b))
                  (list (car b) (third b))
                  nil))
          bindforms))
\end{FramedVerb}\end{center}
\caption{\texttt{do}の実装例．}
\label{fig:ImplementDo}
\end{figure}

第\ref{fig:ImplementDo}図のコードは，実際の処理系で\verb|do|に使われている定義ではない．
展開中に行われる処理を強調するため，
\verb|make-initforms|と\verb|make-stepforms|は独立した関数として分けておいた．
いずれそんなコードも大抵は\verb|defmacro|内に残すようになるだろう．

このマクロの定義により，マクロに何ができるのかが見えてきた．
マクロはLispの式を作る能力を最大限に生かしている．
マクロの展開形を作るコードはそれ自身がプログラムであっても良いのだ．
%}}}
\subsection{マクロのスタイル}   %{{{
良いスタイルはマクロについては意味が違ってくる．
スタイルが問題になるのはコードが人間に読まれるか，Lispに評価されるときだ．
マクロの場合，その両方が普通とは少し違った状況で行われる．

マクロ定義に関わるコードには種類の異なる2個がある：
展開コード，つまりマクロが展開形を生成するために使うコードと，
被展開コード，つまり展開形そのものに現れるコードだ．
スタイルの原則はそれぞれ違っている．
一般的に言って，プログラムの良いスタイルとは明確で効率的であることだ．
これらの原則は2種類のマクロのコードにおいては別々の方向に向かって強調される：
展開コードは効率より明確さを優先し，被展開コードは明確さより効率を優先する．

効率性が一番問題になるのはコンパイル済みコードである訳だが，
コンパイル済みコードの中ではマクロ呼び出しは既に展開済みだ．
展開コードが効率的ならコンパイルが幾分早く済むだろうが，
プログラムの動作の効率には一切違いはない．
マクロ呼び出しの展開はコンパイラの仕事のうち僅かの部分に過ぎないことが多いので，
効率的に展開されるマクロというのも普通はコンパイル速度にも大した影響を及ぼさない．
だから大抵，展開コードはプログラムの初期ヴァージョンを手早く書く感じで書くことができる．
展開コードが不必要な処理をしたりコンシングを多く起こしたからといって，何だと言うのか？
プログラマの時間はプログラムの別の場所を改良するのに費やした方が賢い．
展開コードにおいて明確さと効率のどちらかを選ぶことがあったら，明確さを優先すべきだ．
マクロ定義は一般的に関数定義よりも読み下しづらいが，
それは別々の二つの時点で評価される式が混じっているからだ．
展開コードの効率性の代わりにこの混乱が減らせるのなら，お得な取引と言える．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro our-and (&rest args)
  (case (length args)
    (0 t)
    (1 (car args))
    (t `(if ,(car args)
            (our-and ,@(cdr args))))))

(defmacro our-andb (&rest args)
  (if (null args)
      t
      (labels ((expander (rest)
                         (if (cdr rest)
                             `(if ,(car rest)
                                  ,(expander (cdr rest)))
                             (car rest))))
        (expander args))))
\end{FramedVerb}\end{center}
\caption{\texttt{and}と等価なマクロの例2個．}
\label{fig:AndEquivs}
\end{figure}

例えば一種の\verb|and|をマクロとして定義したいとしよう．
\verb|(and a b c)|は\verb|(if a (if b c))|と等価だから，
第\ref{fig:AndEquivs}図の上の定義のように，\verb|and|は\verb|if|を利用して書ける．
普通のコードを審査する基準からすれば，\verb|our-and|の定義はまずい．
展開コードが再帰的で，
再帰のそれぞれの段階で同じリストの連続した\verb|cdr|部の長さを求めている．
このコードが実行時に評価されるなら，
このマクロは同じ展開を一切無駄なく行う\verb|our-andb|のように定義する方が良いだろう．
しかしマクロ定義としては\verb|our-and|は（勝っているとは言えないが）同程度の出来だ．
再帰のそれぞれの段階で\verb|length|を呼ぶのは非効率的だろうが，
その構成は展開形が条件の数に依存する様子をはっきり表している．

何でもそうだが，例外もある．
Lispではコンパイル時間と実行時間の区別は恣意的なもので，
その区別に基づく法則はどれもやはり恣意的なものだ．
プログラムによっては，コンパイル時間が実行時間なのだ．
プログラムの主目的が何らかの形式の変換で，マクロをそのために利用しているなら，
話は全く違ってくる：
展開コードがプログラムの中心に，展開形がその出力になる，
もちろんそんな状況では展開コードは効率性を念頭に置いて書かれるべきだ．
しかし大抵の展開コードは
（ア）コンパイル速度にのみ影響し，（イ）その影響も大したことはない\wadash
つまり明確さがほぼ必ず一番重要だ．

被展開コードについては，全く逆になる．
マクロの展開形は（特に他人には）読まれることはまず無いので，明確さは大した問題ではない．
禁断の\verb|goto|も展開形では必ずしも禁じられておらず，
評判の悪い\verb|setq|もそれ程嫌がられない．

構造化プログラミングの推進者達が\verb|goto|を憎むのは，
それがソース・コードに及ぼした影響のせいだ．
彼らが有害だと見なすのはマシン語のジャンプ命令ではない\wadash
ソース・コード内で抽象的構造に隠されている限りは問題にならないのだ．
\verb|goto|がLispで非難の対象になっている理由は，楽に隠蔽できるからに他ならない：
代わりに\verb|do|を使えるし，\verb|do|が備わっていなくとも自分で書くことができる．
もちろん新しい抽象的構造を\verb|goto|の上に構築するなら，
どこかに\verb|goto|が存在せざるを得ない．
だから新しいマクロの定義に\verb|go|を使うのは，
既存のマクロが代わりに使えないときなら，必ずしも悪いことではない．

似たように\verb|setq|も，変数がどこで値を得たのかが判り辛くなるので白い目で見られる．
しかしマクロ展開は多くの人が読むものではないので，
普通はマクロ展開の中で創られた変数に\verb|setq|を使うことに害は少ない．
幾つかの組み込みマクロの展開形を見てみれば，\verb|setq|が山程あるだろう．

状況によっては展開形コードでの明確さが一層大事になることがある．
複雑なマクロを書くときは（少なくともデバッグ中に）結局展開形を読む羽目になる．
また単純なマクロでも，展開コードと被展開コードの区別は単なる逆クォートなので，
そんなマクロが格好悪い展開形を生成するのなら，
ソース・コード内でも格好悪さがはっきり見えてしまうだろう．
しかし被展開コードの明確さが問題になるときでも，効率性が依然として優先するべきだ．
プログラム実行時に評価される大部分のコードの中では，効率性が重要なのだ．
マクロ展開では二つの理由からそれが際立つ：
マクロがどこででも使われるせいと，マクロが不可視なせいだ．
マクロはしばしば一般用途のユーティリティを実装するのに使われるが，
それらはプログラムのあらゆる所で呼び出されるものだ．
それ程頻繁に使われるものは非効率的なままで放って置く訳にはいかない．
無害で小さなマクロに見えるものが，全て展開された後には，
プログラム内で無視できない分量を占める．
そんなマクロには，長さから判断して必要と思えるよりも多くの注意が必要だ．
特にコンシングを避けること．
不必要なコンシングを起こすユーティリティは，
それさえなければ効率的なプログラムの動作を鈍化させることにもなりかねない．

展開形コードの効率性に目を向ける理由のもう一つは，それが非常に見え辛い点だ．
関数の実装方法が下手でも，その関数がプログラマの目に入る度にその事実は意識される．
しかしマクロはそうではない．マクロ定義からは展開形の効率の悪さは明らかでないこともある．
展開形コードの非効率性は明らかにならないかも知れないので，一層注意して見るべきなのだ．
%}}}
\subsection{マクロへの依存}   %{{{
関数定義を書き直すと，それを呼び出す関数は自動的に更新後の関数を使うようになる
\footnote{インラインでコンパイルされた関数は別で，
再定義に関してマクロと同様の制限を負っている．}．
ただしマクロについては必ずしも同じようには行かない．
関数定義内にあるマクロ呼び出しは関数がコンパイルされるときに展開形に置換される．
マクロを呼び出す関数がコンパイルされた後にそのマクロを再定義したらどうなるだろうか？
元々のマクロ呼び出しの形跡は残っていないので，関数内の展開形は更新されない．
関数の動作は古いマクロ定義を反映し続けることになる：
\begin{verbatim}
> (defmacro mac (x) `(1+ ,x))
MAC
> (setq fn (compile nil `(lambda (y) (mac y))))
#<Compiled-Function BF7E7E>
> (defmacro mac (x) `(+ ,x 100))
MAC
> (funcall fn 1)
2
\end{verbatim}

マクロを呼ぶコードがマクロそのものの定義前にコンパイルされると似た問題が起こる．
\CLtL2には
「マクロ定義は，マクロの最初の使用よりも先にコンパイラに読まれていなければならない」
とある．
幸運なことにどちらの問題も避けるのは容易だ．
以下の二つの原則を忘れなければ，
古かったり存在しないマクロ定義について思い悩むことはない：
\begin{enumerate}
    \item マクロはそれを呼び出す関数（またはマクロ）の前で定義する．
    \item マクロが再定義されたときは，
        それを（直接または間接的に）呼び出している関数とマクロを全て再コンパイルする．
\end{enumerate}

マクロ定義が確かに最初にコンパイルされるようにするため，
一つのプログラム内で使われるマクロを全て独立したファイルに分ける方法が
これまで提案されてきた．
しかしそれはやり過ぎだ．
\verb|while|のような汎用マクロを独立したファイルに分けるのは理に適っているが，
汎用ユーティリティは関数であれマクロであれ，
プログラムの他の部分とは分けておく方がよい．

マクロにはプログラムのある特定の部分のためだけに書かれたものもあるので，
それらは使う側のコードと一緒に定義されるべきだ．
マクロ定義が呼び出しのどれよりも前に現れる限りコンパイルは上手く行く．
マクロは関数と違うからというだけの理由で全て一緒にしておいても，
コードが読み辛くなるだけのことだ．
%}}}
\subsection{関数からマクロへ}   %{{{
この章では関数をマクロに翻訳する方法を扱う．
最初の1歩は，本当にその必要があるかどうか自問することだ．
関数をインライン宣言するだけで済むのでないだろうか(p. 26)？

しかし関数をマクロに翻訳する方法を考えることにはしっかりした理由がある．
マクロを書きはじめると，関数を書いているような気がしてくることがある．
普通このアプローチでは完璧なマクロは書けないが，少なくともこの感じは手がかりになる．
マクロと関数の関係を理解しておきたい理由には，他にも，それらの違いを理解したいというのもある．
最後に，Lispプログラマにはとにかく関数をマクロに書き換えたいことが時々あるものなのだ．


関数をマクロに翻訳することの難しさは，その関数の持つ性質の数による．
最も翻訳が簡単な部類の関数は
\begin{enumerate}
\item 本体が単一の式から成っていて
\item 仮引数リストには仮引数の名前のみが含まれ
\item （仮引数以外に）新しい変数を創らず
\item 再帰的でなく（また相互再帰的な関数のグループにも含まれず）
\item 本体内で複数回使われる仮引数を持たず
\item 仮引数リスト内で先に現れる仮引数の値より，
    後に現れる仮引数の値の方が本体内で先に使われることがなく
\item フリー変数を含まない
\end{enumerate}
ものだ．
これらの原則を満たす関数の例はCommon Lispの組み込み関数\verb|second|で，
これはリストの第2要素を返す．
その関数はこう定義すればよい：
\begin{verbatim}
(defun second (x) (cadr x))
\end{verbatim}
この場合関数定義は上の条件を全て満たしているので，等価なマクロ定義に翻訳するのは簡単だ．
逆クォートを関数本体の前に付け，
仮引数リストに含まれていたシンボルが出て来る度にコンマを付けるだけでよい：
\begin{verbatim}
(defmacro second (x) `(cadr ,x))
\end{verbatim}
もちろんこのマクロは関数とまったく同じ条件で呼び出すことはできない．
\verb|apply|や\verb|funcall|の第1引数としては渡せないし，
呼出側の関数が新たなローカルな束縛を生むような環境では使うべきでない．
それでも普通のインライン呼び出しでは，
マクロ\verb|second|は関数\verb|second|と同じ動作をするはずだ．

マクロは単一の式に展開されなければならないので，
本体に複数の式が含まれるときには少し違う方法を使う．
条件1が満たされないときには\verb|progn|を追加すればよい．
つまり関数\verb|noisy-second|は：
\begin{verbatim}
(defun noisy-second (x)
  (princ "Someone is taking a cadr!")
  (cadr x))
\end{verbatim}
次のマクロ定義として翻訳できる：
\begin{verbatim}
(defmacro noisy-second (x)
  `(progn
     (princ "Someone is taking a cadr!")
     (cadr ,x)))
\end{verbatim}

関数が\verb|&rest|または\verb|&body|仮引数を使っていて条件2が満たされないときは，
仮引数に関してだけ方法を変える．
ただコンマを前に付けるのではなく，
仮引数の中身が\verb|list|の呼び出しの中に切り貼りされなければならない．
よって
\begin{verbatim}
(defun sum (&rest args)
  (apply #'+ args))
\end{verbatim}
は
\begin{verbatim}
(defmacro sum (&rest args)
  `(apply #'+ (list ,@args)))
\end{verbatim}
となるが，この場合は次のようにした方がよい：
\begin{verbatim}
(defmacro sum (&rest args)
  `(+ ,@args))
\end{verbatim}

条件3が満たされないとき\wadash 関数本体内で新しい変数が創られるとき\wadash は，
コンマを付ける方法を修正しなければならない．
仮引数リストに含まれるシンボル全ての前にコンマを付けるのではなく，
仮引数を参照しているものにのみコンマを付ける．
例えば次の例では
\begin{verbatim}
(defun foo (x y z)
  (list x (let ((x y))
            (list x z))))
\end{verbatim}
\verb|x|の内後ろの二つは仮引数の\verb|x|を参照していない．
2番目の\verb|x|は一切評価の対象にならず，
3番目は\verb|let|の創り出した新しい変数を参照している．
だから1番目にだけコンマを付ける：
\begin{verbatim}
(defmacro foo (x y z)
  `(list ,x (let ((x ,y))
              (list x ,z))))
\end{verbatim}
条件4～6が満たされなくとも関数をマクロに翻訳できることもあるが，
これらの内容は後で独立して扱う．
マクロにおける再帰については第10.4章で，
評価の重複と評価順の混乱の危険性についてはそれぞれ第10.1章と10.2章で扱う．

条件7については，xienページで触れたエラーに似た技を使ってクロージャをマクロで真似ることができる．
しかしこれは程度の低い技であり，この本の基調に馴染まないので，
詳しく扱うことはしない．
%}}}
\subsection{シンボル・マクロ}   %{{{
\CLtL2でCommon Lispに新種のマクロが導入された\wadash シンボル・マクロだ．
普通のマクロ呼び出しの見掛けが関数呼び出しに似ているのに対して，
シンボル・マクロの「呼び出し」の見掛けはシンボルに似ている．

シンボル・マクロはローカルにのみ定義できる．
スペシャル式\verb|symbol-macrolet|を使うと，
その本体内では唯のシンボルが式のように振る舞うようになる：
\begin{verbatim}
> (symbol-macrolet ((hi (progn (print "Howdy")
                               1)))
                   (+ hi 2))
"Howdy"
3
\end{verbatim}
\verb|symbol-macrolet|の本体は引数の場所にある\verb|hi|が
全て\verb|(progn (print "Howdy") 1)|で置き換えられたかのように評価される．

概念的には，シンボル・マクロは引数をとらないマクロに似ている．
引数がなければ，マクロは見掛け上の省略形に過ぎない．
しかしシンボル・マクロが無益だと言いたいのではない．
それは第15章と第18章で使われているが，後者では必要不可欠な役目を持っている．
%}}}

%}}}
\section{いつマクロを使うべきか} %{{{
ある関数が，本当にマクロであるよりも関数であった方が良いというのは，
どうしたら分かるだろうか？
マクロが必要な場合とそうでない場合の間には，大抵明確な区別がある．
基本的には関数を使うべきだ：
関数で間に合う所にマクロを使うのはエレガントでない．
マクロが何か特定の利益を与えるときのみそれを使うべきなのだ．

マクロが利益を与えるときとはいつだろうか？
それがこの章の主題だ．
普通この疑問は，改良を目指すときでなく必要に迫られた上で発せられる．
マクロで実現できることの大部分は，関数ではできない．
第8.1節ではマクロとしてのみ実装できるオペレータの種類を列挙する．
だが境界線上に立つような場合もわずかにある（しかしこれは興味深い）．
つまりオペレータを関数で書いてもマクロで書いてもよいような状況だ．
そのような状況について，第8.2節ではマクロについての賛否両論を挙げる．
最後に，マクロに何ができるのかを考慮した上で，
第8.3節では関連した疑問について考える．
人はマクロでどんなことを行うものなのだろうか？
\subsection{他に何も関係しないとき}   %{{{
プログラム内の数個所に似通ったコードが表れているとき，サブルーチンを書き，
それらをサブルーチン呼出しで置き換えるのは，よいデザインのための一般原則だ．
この原則をLispプログラムに適用するとき，
「サブルーチン」を関数にすべきかマクロにすべきか決めなければならない．

関数ではなくマクロを書こうと用意に決心できることがある．
マクロのみが必要なことを実現できるときだ．
\verb|1+| のような関数は，関数としてもマクロとしても書けるかもしれない．
\begin{verbatim}
(defun 1+ (x) (+ 1 x))

(defmacro 1+ (x) `(+ 1 ,x))
\end{verbatim}
しかし第7.3節の\verb|while|は，マクロでないと定義できない：
\begin{verbatim}
(defmacro while (test &body body)
  `(do ()
             ((not ,test))
          ,@body))
\end{verbatim}
このマクロの動作を関数で真似る方法はない．
\verb|while|の定義では，本体として渡された式を\verb|do|の本体内に張り込むようになっているが，
これはテスト式が\verb|nil|を返したときのみ評価される．
どんな関数にもそれは無理だ：
関数呼び出しでは，全ての引数は関数の呼び出しよりも前に評価されるからだ．

確かにマクロが必要というとき，マクロに何を求めているのだろうか？
マクロにできて関数にできないことは2つある：
マクロは引数の評価を制御（または抑制）でき，
また呼び出し側のソースコードそのものへと展開される．
結局，マクロが必要なアプリケーションには，これらの性質の片方または両方を必要なのだ．

簡単に説明するときの「マクロは引数を評価しない」というのは少し間違っていて，
こう言うと正確になる．
マクロはマクロ呼び出し内の引数の評価を制御する．
評価回数は引数がマクロの展開コードのどこに置かれるかによるが，
1回でも複数回でも良いし，全く評価しないこともある．
マクロでのこの制御の使われ方は主に次の4通りだ：

\begin{enumerate}
\item 変形．
Common Lispのマクロ\verb|setf|は引数を評価前に取り出す類のものだ．
組み込みのアクセス関数には，しばしば逆の動作を行う関数がある．
その目的はアクセス関数が取ってきたものを設定することだ．
\verb|car|については\verb|rplaca|，\verb|ofcdr|，\verb|rplacd|等が当てはまる。
\verb|setf|を使うと，そういったアクセス関数を設定されるべき変数と同じように呼び出せる．
例えば\verb|(setf (car x) 'a)|は\verb|(progn (rplaca x 'a) 'a)|に展開され得る．

この技を実現するには，\verb|setf|はその第1引数の内部を見なければならない．
上の場合で\verb|rplaca|が必要だと知るためには，
\verb|setf|には第1引数が\verb|car|で始まる式であることが見えなければならない．
よって\verb|setf|を始めとする，引数の変形を行うオペレータは，
どれもマクロとして書かなければならない．
\item 変数束縛．
レキシカル変数はソースコード内に直接書かれなければならない．
例えば\verb|setq|の第1引数は評価されないので、
\verb|setq|の上に構築されたものは全て\verb|setq|へと展開されるマクロでなければならない．
\verb|setq|を呼び出す関数ではだめだ．
それは引数が$\lambda$式の仮引数として現れる\verb|let|などのオペレータや，
\verb|lets|へと展開される\verb|do|等のマクロについても同様だ。
引数のレキシカルな束縛を変更するための新オペレータは，
いずれもマクロとして書かれなければならない。
\item 条件分岐による評価．
関数の引数は全て評価される．
\verb|when|のような制御構文では，ある引数は特定の条件下でのみ評価される．
そのような柔軟性はマクロでのみ得られる．
\item 複数回の評価．
関数の引数は全て評価されるだけでなく，きっかり1回評価される．
マクロは\verb|do|のような制御構文の定義に使われるが，この場合，
ある引数は繰り返し評価されなければならない．
\end{enumerate}
マクロのインライン展開を活用する方法もいくつかある。
そこで展開形は例えばマクロ呼び出しのレキシカルコンテキスト内に現れることを強調したい．
なぜなら3通りのうち2通りのマクロがその事実に依拠しているからだ．
すなわち、
\begin{enumerate}
\setcounter{enumi}{4}
\item 呼び出し側環境を利用する．
マクロは，呼び出し側のコンテキストに束縛された変数を含む展開形を生成できる．
下のマクロの動作は，\verb|foo|が呼ばれた場所での\verb|y|の束縛に依存する．
\begin{verbatim}
(defmacro foo (x)
  `(+ ,x y))
\end{verbatim}
普通この類のレキシカルな結び付きは喜びの源というよりも伝染病の感染源として見なされる．
通常，そのようなマクロを書くのは悪いスタイルだ．
関数プログラミングの理想はマクロにも同様に適用される：
マクロは引数を通じて相互作用することが望ましい．
実際，呼出側環境を利用することは滅多に必要にならず，
そのような状況が起きたとしても，それは大抵誤りによるものだ（第9章を参照）．
この本の中の全てのマクロのうち，継続を渡すマクロ（第20章）とATNコンパイラ（第23章）のみが
その方法で呼び出し側環境を利用している．
\item 新しい環境を包み込む．
マクロは引数を新たなレキシカル環境で評価させることもできる．
古典的な例は\verb|let|で，\verb|lambda|の上にマクロを被せることで実装できる（penpenページ）．
\verb|(let ((y 2)) (+ x y))|等の式の実行部本体の中では，
\verb|y|は新しい変数を指すことになる．
\item 関数呼び出しを節約する．
マクロの展開結果をインライン挿入することの3つ目の結果は，
コンパイル後のコードではマクロ呼び出しに関わるオーヴァヘッドが一切ないことだ．
実行時には，マクロ呼び出しは展開形に置き換え済みになっている．
(原則的にはインライン宣言された関数でも同じことだが)
\end{enumerate}

驚いたことに第5番目と第6番目の用法は，
意図せずに使われたときは，変数捕捉の問題を引き起こす．
これはマクロを書くときに恐らく一番恐ろしいことだ．
変数捕捉については第9章で論じる．

マクロの利用法には7通りあると言う代わりに，6通り半あると言った方がよいだろう．
理想の世界では全てのCommon Lispコンパイラがインライン宣言に従い，
関数呼び出しの節約はマクロではなくインライン関数の仕事になっていることだろう．
理想の世界は読者への課題として残しておく．
%}}}
\subsection{マクロと関数どちらがよい？}   %{{{
前節では判断の容易なケースを扱った。
引数に、評価前にアクセスするオペレータは全てマクロで書かなければならない。
他に選択肢はないからだ。
それではマクロでも関数でも書けるようなオペレータはどうだろうか？
例えば引数の平均値を返すオペレータ\verb|avg|を考えてみよう．
次のように関数として書くことができる．
\begin{verbatim}
(defun avg (&rest args)
  (/ (apply #'+ args) (length args)))
\end{verbatim}
しかし次のようにマクロとして書いた方がよい．
\begin{verbatim}
(defmacro avg (&rest args)
  `(/ (+ ,@args) ,(length args)))
\end{verbatim}
関数版\verb|avg|は呼ばれる度に\verb|length|を呼ぶが，それは不必要だ．
コンパイル時には引数の値までは不明かもしれないが，それが幾つあるかは分かる．
よって\verb|length|の呼び出しはそのときに済ませた方がよい．
似たような選択を迫られたときに考慮すべき点は以下の通りだ．

\begin{center}マクロの長所\end{center}
\begin{enumerate}
\item コンパイル時の計算．
マクロ呼び出しには，2つの時点での処理が関わってくる．
マクロの展開時と，展開形の評価時だ．
Lispプログラムでのマクロ展開は全てプログラムがコンパイルされたときに行われ，
コンパイル時に実行できるどのような計算も，実行時にプログラムを遅くすることはない．
オペレータが仕事の一部をマクロ展開の段階で済ませるように書けるなら，
マクロとして書く方が効率がよいだろう．
賢いコンパイラでもできないようなことがあれば，
結局実行時に関数がこなすことになるのだから．
第13章では\verb|avg|のように展開時に仕事を行うマクロについて説明する．
\item Lispとの緊密な連携．
関数ではなくマクロを使うと，プログラムをLispと緊密に連携させられることがある．
ある問題を解くプログラムを書く代わりに，
マクロを使ってその問題をLispが既に解法を知っているような問題へ変形できるときがある．
このアプローチが可能なときは，大抵プログラムは小さくかつ効率的になる：
Lispが処理を代わりに行ってくれるので小さくなり，
Lisp処理系の製品は一般的にユーザのプログラムより無駄を削いであるから効率がよくなる，という訳だ．
この長所は主に埋め込み言語で明らかになるが，それについての説明は第19章から始まる．
\item 関数呼び出しの節約．
マクロ呼び出しは，書かれた所に直接展開される．
だからよく使われるコードのまとまりをマクロとして定義しておけば，
それが使われる度に関数を呼び出さなくともよい．
Lispの古い方言では，プログラマは実行時の関数呼び出しを節約するために，
マクロのこの性質を活用していた．
Common Lispでは，この仕事はインライン宣言された関数が代わりに行うものとされている．

関数をインライン宣言することで，
コンパイルされたら呼出側コードの中に埋め込まれるよう指示できる．
マクロと全く同じだ．
しかし，ここでは理想と現実のギャップが出てくる．
\CLtL2 (p. 229)には「コンパイラがこの宣言を無視するのはフリーである」とあり，
幾つかのCommon Lispコンパイラは確かに無視している．
そのようなコンパイラを使わざるを得ないのなら，
関数呼び出しの節約にマクロを使うのも認められるだろう．
\end{enumerate}
効率とLispとの緊密な連携との長所が相俟って，
マクロを使おうという考えが強い説得力を持つ場合がある．
第19章のクエリ・コンパイラでは，コンパイル時に移せる計算の量がとても大きいので，
プログラム全体を1つの巨大なマクロに変えてしまってよいといえる．
この変換はスピードのために行われたのだが，
プログラムをLispと緊密にすることにもつながっている．
新しいヴァージョンではクエリの中で数値評価などのLispの式を簡単に使えるのだ．

\begin{center}マクロの短所\end{center}
\begin{enumerate}
\item 関数はデータだが，マクロはコンパイラへの指示に近い．
関数は（例えば\verb|apply|に）引数として渡すことも，関数から返すことも，
データ構造内に格納することもできる．
マクロではそれらはどれも不可能だ．
これらはマクロ呼び出しを$\lambda$式で包むことで実現できる場合がある．
この方法は例えばマクロに\verb|apply|や\verb|funcall|を適用したいときに使える．
\begin{verbatim}
> (funcall #'(lambda (x y) (avg x y)) 1 3)
2
\end{verbatim}
しかしこの方法は不便だし，必ず使えるというものではない．
\verb|avg|のように，マクロに\verb@&rest@パラメータがあっても，
それに可変個の引数を渡す方法はない．
\item ソースコードの明確さ．
マクロ定義は，同等な関数の定義より読み辛くなりがちだ．
だから何かをマクロとして書いてもプログラムが大して進歩する訳でもないなら，
代わりに関数を使った方がよい．
\item 実行時の明確さ．
マクロは関数よりデバッグし辛いことがある．
多数のマクロ呼び出しを含むコードで実行時エラーに出くわしても，
\verb|backtrace|で見えるコードはそれら全てのマクロ呼び出しの展開形からなり，
元々書いたコードとは似ても似つかないかもしれない．

マクロは展開時に消えてしまうので，実行時には動作の説明がつかない．
普通は\verb|trace|でマクロが呼び出される様子を見ることはできない．
たとえ使っても，\verb|trace|はマクロ呼び出しそのものではなく，
マクロを展開する関数の呼び出しを表示するだろう．
\item 再帰．
マクロ内で再帰を使うのは，関数のときほど簡単でない．
マクロ展開の結果の関数は再帰的でもよいが，展開そのものは再帰的であってはならないからだ．
第10.4章でマクロにおける再帰を扱う．
\end{enumerate}

いつマクロを使うかを決める際には，これらの考慮のバランスを取らなければならない．
どちらが有利かを教えてくれるのは経験のみだ．
しかしこの後の章のマクロの例は，マクロが便利な状況を大体カヴァーしている．
考え中のマクロがここでの例に似ているなら，そのように書いても大丈夫だろう．

最後に言いたいのは，実行時の明確さ（ポイント6）はほとんど問題にならないということだ．
大量のマクロを含むコードのデバッグは，思った程難しくないだろう．
マクロ定義が数百行に及ぶのなら，実行時にその展開形をデバッグするのは嫌になることだ．
しかし少なくともユーティリティは，小さく信頼できる層として書かれることが多い．
一般的には定義は15行以下になる．
だからもし\verb|backtrace|を通してコードとにらめっこする羽目になっても，
そのようなマクロが目をひどく曇らせることはないだろう．
%}}}
\subsection{マクロの応用例}   %{{{
マクロで何ができるのかを考えた上で，次に浮かぶ質問はこうだ：
マクロをどのような応用に使えばよいのだろう？~%
マクロの利用についての一般的な説明に一番近いのは，
マクロは主に構文変換に使われると言うことだろう．
マクロの適用範囲が制限されていると言いたいのではない．
Lispプログラムはリストから作られるが
\footnote{リストがコンパイラへの入力であるという意味で「作られる」ということだ．
昔の方言の幾つかとは違い，現在では関数はリストから作られてはいない．}，
リストはLispの持つデータ構造であり，実際「構文変換」は大変奥が深い．
第19-24章には，構文変換が目的であると言ってよいプログラムの全体を載せた．
そしてそれは，結局は全てマクロである．

マクロの応用は，
\verb|while|のような小さな汎用マクロと，
この後の章で定義する大規模で特別な用途を持ったマクロとの間の連続体を形成する．
端点の片方はユーティリティ，
つまりどのLisp処理系も組み込みで持っているマクロの類似品だ．
それは普通小さく，一般的で，独立して書かれている．
しかし特定の種類のプログラムのためのユーティリティを書くこともできる．
例えば，グラフィックス・プログラムの中で使うようなマクロが充実してきたときには，
それらはグラフィックスのためのプログラミング言語に似てくるだろう．
連続体のもう片方の端点は，
Lispとは明らかに異なった言語でプログラム全体を書けるようにしてくれるマクロだ．
この方法で使われるマクロは，埋め込み言語を実装していると言われる．

ユーティリティは，ボトムアップ・スタイルからの帰結の第1番目である．
多層構造を作るにはプログラムが小さ過ぎるような場合ですら，
最下層であるLispの上に層を加えておくことには利点があるかもしれない．
ユーティリティ\verb|nil!|は引数にnilを代入するものだが，
マクロ以外では定義できない．
\begin{verbatim}
(defmacro nil! (x)
   `(setf ,x nil))
\end{verbatim}
\verb|nil!|を見ると，
「何もしてないじゃないか，打ち込む文字を減らしてるだけだ」と言いたくなる．
それは本当だが，マクロのやっていることと言ったら，打ち込む文字の節約が全てだ．
似たような考え方をしたいなら，
コンパイラの仕事はマシン語を打ち込む作業を省くことだと言える．
ユーティリティの効果は累積していくので，その価値は見過ごせない．
単純なマクロを複数の層に重ねることで，
エレガントなプログラムと理解しがたいプログラムとの違いが分かれる．

ほとんどのユーティリティは埋め込まれたパターンだ．
自分のコードの中のパターンに気付いたら，それをユーティリティに変えることを考えよう．
パターンとはまさにコンピュータの得意分野だ．
代わりに仕事をしてくれるプログラムが手に入るというのに，
どうして頭を悩ます必要があるのだろうか？~%
何かのプログラムを書いているとき，
色々な場所で同じ構造を持った\verb|do|ループを使っていたことに気付いたとしよう．\\
\texttt{%
(do ()\\[-4pt]
~~((not \formal{条件} ))\\[-4pt]
~~\formal{コード本体} )%
}\\
コード内で繰り返されるパターンに気付いたとき，
そのパターンにはしばしば名前が付けられる．
この場合のパターンは\verb|while|という名前だ．
それを新しいユーティリティ内で提供したいときには，
条件評価と複数回の評価が必要なので，
マクロを使わなければならない．
ruriruriページにある下の定義を使って\verb|while|を定義すると，
\begin{verbatim}
(defmacro while (test &body body)
  `(do ()
     ((not ,test))
     ,@body))
\end{verbatim}
上のパターン例は次のように書き換えられる．\\
\texttt{%
(while \textrm{$\left<\right.$条件$\left.\right>$} \\[-4pt]
~~\textrm{$\left<\right.$コード本体$\left.\right>$} )%
}\\
そうすることでコードは短くなり，更に動作内容がはっきりと示される．

引数を変形できる能力のおかげで，マクロはインタフェイスを書くのに便利だ．
適切なマクロを使えば，
長く込み入った式が必要な筈のときでも短く簡潔な式が書ける．
GUIのせいでエンド・ユーザのためにそのようなマクロを書く必要は減ってきたが，
プログラマがこの類のマクロを使うことは減らない．
一番馴染深い例は\verb|defun|だろう．
これは関数を束縛するもので，見掛け上はPascalやC等の言語の関数定義に似ている．
第2章では以下の2つの式はほぼ同じ効果を持つことに触れた．
\begin{verbatim}
(defun foo (x) (* x 2))

(setf (symbol-function 'foo)
      #'(lambda (x) (* x 2)))
\end{verbatim}
よって\verb|defun|は前者を後者へ変換するマクロとして実装できる．
\verb|defun|は次のように書かれていると想像できる
\footnote{明確さのために，
この例では\texttt{defun}が行わなければならない細々とした仕事を全て無視している．}．
\begin{verbatim}
(defmacro our-defun (name parms &body body)
  `(progn
     (setf (symbol-function ',name)
           #'(lambda ,parms (block ,name ,@body)))
     ',name))
\end{verbatim}
\verb|while|や\verb|nil!|等のマクロは，汎用ユーティリティであると言える．
それらはどんなLispプログラムで使ってもよい．
しかし特定の領域のためのユーティリティを書いてもよい．
基盤のLispが，拡張のための言語が利用できる唯一のレベルだと考える理由はない．
例えばCADプログラムを書いているのなら，2層に分けて書くことが一番の結果を生むだろう．
CADプログラムのための言語（お好みならツールキットという穏やかな言葉でもいいが）と，
その層の中で書かれた，ある特定のアプリケーションだ．

\begin{figure}\begin{center}\begin{FramedVerb}
(defun move-objs (objs dx dy)
  (multiple-value-bind (x0 y0 x1 y1) (bounds objs)
    (dolist (o objs)
      (incf (obj-x o) dx)
      (incf (obj-y o) dy))
    (multiple-value-bind (xa ya xb yb) (bounds objs)
      (redraw (min x0 xa) (min y0 ya)
              (max x1 xb) (max y1 yb)))))

(defun scale-objs (objs factor)
  (multiple-value-bind (x0 y0 x1 y1) (bounds objs)
    (dolist (o objs)
      (setf (obj-dx o) (* (obj-dx o) factor)
            (obj-dy o) (* (obj-dy o) factor)))
    (multiple-value-bind (xa ya xb yb) (bounds objs)
      (redraw (min x0 xa) (min y0 ya)
              (max x1 xb) (max y1 yb)))))
\end{FramedVerb}\end{center}
\caption{元々の\texttt{move}と\texttt{scale}．}
\label{fig:OriginalMoveAndScale}
\end{figure}

他のプログラミング言語では当り前だと思われているあれこれの区別は，
Lispではぼやけている．
他のプログラミング言語では，
コンパイル時と実行時，プログラムとデータ，プログラミング言語とプログラムの間には，
概念的な区別が確かに存在する．
Lispでは，これらの区別は言葉の上での慣習として存在するに過ぎない．
例えば，プログラミング言語とプログラムを区切る線は存在しないのだ．
問題に適した所に，好きなように手書きの線を引いてよい．
背後のコードの層をツールキットと呼ぶかプログラミング言語と呼ぶかは，
全く用語の問題に過ぎない．
プログラミング言語とみなすことの長所の一つは，
Lispでやっているのと同じように，それをユーティリティで拡張する気になれることだ．

インタラクティブな2Dドロー・プログラムを書いているとしよう．
話を簡単にするため，そのプログラムが扱うオブジェクトは線分のみとする．
線分は始点\verb|x|，\verb|y|とベクタ\verb|dx|，\verb|dy|で表現される．
その種のプログラムが対応しなければならない操作に，
オブジェクトのグループの平行移動がある．
それが第\ref{fig:Move-Objs}図の関数\verb|move-objs|の役目だ．
効率を考え，操作毎にスクリーン全体を再描画することは避けたい\wadash
変更のあった部分だけを再描画したい．
そのため2個ある\verb|bounds|の呼び出しは，
オブジェクトのグループを囲む長方形を表す4個の座標
$(\min \mathtt{x}, \min \mathtt{y}, \max \mathtt{x}, \max \mathtt{y})$を返す．
\verb|move-objs|の動作部分は，
移動前と移動後の長方形をそれぞれ見つけるための
\verb|bounds|の呼び出し2個に挟まれており，影響を受けた領域全体を再描画する．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro with-redraw ((var objs) &body body)
  (let ((gob (gensym))
        (x0 (gensym)) (y0 (gensym))
        (x1 (gensym)) (y1 (gensym)))
    `(let ((,gob ,objs))
       (multiple-value-bind (,x0 ,y0 ,x1 ,y1) (bounds ,gob)
         (dolist (,var ,gob) ,@body)
         (multiple-value-bind (xa ya xb yb) (bounds ,gob)
           (redraw (min ,x0 xa) (min ,y0 ya)
                   (max ,x1 xb) (max ,y1 yb)))))))

(defun move-objs (objs dx dy)
  (with-redraw (o objs)
               (incf (obj-x o) dx)
               (incf (obj-y o) dy)))

(defun scale-objs (objs factor)
  (with-redraw (o objs)
               (setf (obj-dx o) (* (obj-dx o) factor)
                     (obj-dy o) (* (obj-dy o) factor))))
\end{FramedVerb}\end{center}
\caption{filletedされた\texttt{move}と\texttt{scale}．}
\label{fig:Move-Objs}
\end{figure}

関数\verb|scale-objs|は，オブジェクトのグループの大きさを変えるためのものだ．
拡大率に応じてグループを囲む領域は広がったり狭まったりするので，
この関数も\verb|bounds|の2個の呼び出しの間で動作しなければならない．
プログラムを書き進めていけば，このパターンが更に現れるだろう．
回転，裏返し，転置等だ．

マクロによってこれらの関数が共通して持つコードを抽象化することができる．
第\ref{fig:Move-Objs}図のマクロ\verb|with-redraw|は第\ref{fig:OriginalMoveAndScale}の
関数が共有している骨格を与えている
\footnote{このマクロの定義にはgensymが使われているので，次章の知識が必要になる．
その目的はまもなく説明する．}．
その結果，それらの関数はそれぞれ4行の長さで定義できた．
これら2つの関数に利用できたことでその新マクロはすでに簡潔さの点で元が取れたことになる．
そしてこれらの関数は，スクリーン再描画の詳細が抽象化されたら，何と明確になったことだろう．

\verb|with-redraw|は，インタラクティブ・ドロー・プログラムを書くための
プログラミング言語の一構造として捉えることができる．
そのようなマクロを更に整備していけば，
それらは名前の上だけでなく，実際にプログラミング言語に似てくるだろう．
そして書いているアプリケーション自身も，
その特定の用途のために定義されたプログラミング言語で書けばこうなるだろうか，
と思える程エレガントなものに変わっていく．

マクロの主要な利用法のもう一つは，埋め込み言語の実装だ．
Lispはプログラミング言語を書くのに際立って優れたプログラミング言語だ．
それはLispプログラムはリストとして表現できるが，
Lispにはそのように表現されたプログラムに対する組み込みパーサ\verb|(read)|と
コンパイラ\verb|(compile)|があるからだ．
大抵は\verb|compile|を呼ぶ必要もない．
埋め込み言語は，変換を行うコードをコンパイルすることで自動的にコンパイルさせられる
（pnkページ）．

埋め込み言語とはLispの上に書かれたというよりは混じり合って書かれたものである．
そのため，文法はLispとそのプログラミング言語に特有の構造との混合になる．
埋め込み言語を実装する素朴な方法は，Lispでそのインタプリタを書くことだ．
もし可能ならばもっと良いアプローチがある．
変換によってそのプログラミング言語を実装することだ．
すなわち，評価させたいときにはLispインタプリタが動作するようなLispコードに
個々の式を変換するのだ．
そこにマクロの活躍の場がある．
マクロの仕事は正にある種の式を別の式に変換することだから，
埋め込み言語を書く際にはマクロは自然な選択だ．

一般的には，埋め込み言語はなるべく変換によって実装できた方がよい．
第1に，労力が少なくて済む．
例えば新しいプログラミング言語に算術演算機能があれば，
数値を表現し，操作することの面倒に一切関わらずに済む．
Lispの算術能力が目的に取って十分なものなら，
新しい算術式を等価なLispの算術式に変換し，残りはLispに任せるだけで済む．

普通，変換を使うと，埋め込み言語を速くすることにもなる．
インタプリタは本質的に速度に関して不利である．
例えばあるコードがループ内にあるとしよう．
コンパイルされたコードでは1回で済む動作を，
インタプリタでは繰り返しの度にしなれけばならないことがしばしばある．
そのため自前のインタプリタによる埋め込み言語は，
そのインタプリタそのものがコンパイルされたときでも遅い．
しかし埋め込み言語の式がLispの式に変換されていれば，
そのコードはLispコンパイラでコンパイルできる．
そのように実装された埋め込み言語では，
実行時のインタプリテーションのオーヴァヘッドに一切悩まされずに済む．
自分のプログラミング言語のための本当のコンパイラを書くのでなければ，
マクロによって一番の性能が得られるだろう．
実際，埋め込み言語を変換するマクロは，埋め込み言語のコンパイラと見なせる\wadash
その動作のほとんどを既存のLispコンパイラに依存しているだけのことだ．

第19-25章は全てその話題にあてられているので，
ここでは埋め込み言語の例について考えることはしない．
第19章では特に埋め込み言語のインタプリティングと変換の違いを扱い，
その2通りで同じプログラミング言語を実装して見せる．

Common Lispについてのある本では，マクロの適用領域が限られていると警告している．
その根拠として，\CLtL1で定義されているオペレータのうち，
マクロは10\%にも満たないことを引用している．
これは家が煉瓦で作られているから，家具も煉瓦で作ろうと言うようなものだ．
Common Lispプログラム内のマクロの比率は，その用途に完全に依存する．
マクロを一切使わないプログラムもあれば，全てマクロから成るプログラムもある．
%}}}
%}}}
\section{変数捕捉} %{{{
マクロの弱点は，変数捕捉と呼ばれる問題だ．
変数捕捉はマクロ展開が名前の衝突を起こしたときに生じる．
つまりあるシンボルが別のコンテキストの変数を参照してしまったときだ．
うっかりして起きた変数捕捉が，ものすごく些細なバグにつながることもあり得る．
この章では，どのようにそれを予測し，避けるかを扱う．
しかしながら意図的な変数捕捉は便利なプログラミング技法であり，
第14章はそれを利用したマクロがほとんどだ．

\subsection{マクロ引数の捕捉}   %{{{
意図しない変数捕捉を弱点に持つマクロとは，バグのあるマクロと言ってよい．
そのようなマクロを書くのを防ぐには，変数捕捉がいつ起きるのかを正確に知らなければならない．
実際の変数捕捉の元を辿ると，以下の2通りの状況に行き着く．
マクロ引数の捕捉とフリーシンボルの捕捉だ．
マクロ引数の捕捉とは，マクロ呼び出しの引数として渡されたシンボルが，
不注意によってマクロ展開そのものによって生成された変数を参照してしまうことである．
マクロ\verb|for|の，以下の定義を考えてみよう．
これはPascalの\verb|for|構文のように，本体となる式の実行を繰り返すものだ．
\begin{verbatim}
(defmacro for ((var start stop) &body body)          ; 誤り
  `(do ((,var ,start (1+ ,var))
        (limit ,stop))
     ((> ,var limit))
     ,@body))
\end{verbatim}
このマクロは初見では正しいように見える．
それどころかちゃんと動作までするようだ．
\begin{verbatim}
> (for (x 1 5)
       (princ x))
12345
NIL
\end{verbatim}
実際，誤りは微妙なもので，上の形のマクロを数百回使っても全て完璧に動作するかも知れない．
しかし，下のように呼び出さなければ，の話だ．
\begin{verbatim}
(for (limit 1 5)
  (princ limit))
\end{verbatim}
この式も上のものと同じ効果を持つと思える．
しかしこれは何も表示しない．エラーを起こすのだ．
理由を知るために，その展開形を見てみよう．
\begin{verbatim}
(do ((limit 1 (1+ limit))
         (limit 5))
        ((> limit limit))
  (princ limit))
\end{verbatim}
これで何が誤りを引き起こしたのかは明らかだ．
マクロの展開形についてローカルなシンボルと，マクロに引数として渡されたシンボルとの間に，
名前の衝突があったのだ．
展開形が\verb|limit|を捕捉していた．
結局それが同じ\verb|do|の中で2回現れることになり，エラーになったのだ．

変数捕捉によるエラーは稀だが，頻度が少ない分，質の悪いものだ．
先程の変数捕捉は比較的大人しい\wadash
少なくとも，ここではエラーが起きた．
しかし大抵は，変数捕捉を起こすマクロは，
何かがおかしいという兆候を何も示さずに誤った結果をもたらす．
下の場合では，
\begin{verbatim}
> (let ((limit 5))
    (for (i 1 10)
         (when (> i limit)
           (princ i))))
NIL
\end{verbatim}
結果のコードはエラーを出さず，しかし何の動作もしない．
%}}}
\subsection{フリーシンボルの捕捉}   %{{{
起こる頻度は少ないが，
不注意からマクロ定義そのものが，マクロが展開された環境内の束縛を参照することがある．
あるプログラムで，問題が起きたときユーザに警告を発する代わりに，
後ほど検討するために警告をリストに蓄えたいとしよう．
ある人はマクロ\verb|gripe|を書いた．
これは警告メッセージを取り，それをグローバルなリスト\verb|w|に付け加えるものだ．
\begin{verbatim}
(defvar w nil)

(defmacro gripe (warning)                        ; 誤り
  `(progn (setq w (nconc w (list ,warning)))
          nil))
\end{verbatim}
別のある人は関数\verb|sample-ratio|を書こうと思った．
それは2つのリストの長さの比を返すものだ．
また，どちらかのリストが1個以下の要素しか持たなければ，
代わりに \verb|nil| を返し，同時に「統計的に意味の見出せない状況だ」と警告を発する．
(実際の警告はもっと丁寧なのだろうが，警告内容はこの例にとってはどうでもよい．)
\begin{verbatim}
(defun sample-ratio (v w)
  (let ((vn (length v)) (wn (length w)))
    (if (or (< vn 2) (< wn 2))
      (gripe "sample < 2")
      (/ vn wn))))
\end{verbatim}
\verb|sample-ratio|が$\mathtt{w} = \mathtt{(b)}$という状態で呼ばれたら，
「引数の一つが要素を1個しか持っていない，統計的に無意味だ」
と警告を発しようとするだろう．
しかし\verb|gripe|の呼び出しが展開されると，
\verb|sample-ratio|が下のように定義されたかのような結果になる．
\begin{verbatim}
(defun sample-ratio (v w)
  (let ((vn (length v)) (wn (length w)))
    (if (or (< vn 2) (< wn 2))
      (progn (setq w (nconc w (list "sample < 2")))
             nil)
      (/ vn wn))))
\end{verbatim}

ここでの問題は，\verb|gripe|の使われたコンテキストでは
\verb|w|にはそれ自身のローカルな束縛があるということだ．
警告はグローバルな警告リストに保存されずに，
\verb|sample-ratio|の仮引数の1つの末尾に\verb|nconc|されてしまう．
警告が失われるだけではない．
リスト\verb|(b)|は恐らくプログラムのどこかでデータとして使われるのだろうが，
後ろに余計な文字列がくっついてしまう．
\begin{verbatim}
> (let ((lst '(b)))
    (sample-ratio nil lst)
    lst)
(B "sample < 2")
> w
NIL
\end{verbatim}
%}}}
\subsection{捕捉はいつ起きるのか}   %{{{
マクロ定義を見て次の2種類の捕捉から起き得る問題を予測できるようになりたいと，
多くのマクロ作者が願い続けてきた．
捕捉は微妙な問題で，
捕捉され得るシンボルがどのようにプログラムに障害をばら撒くかを全て予測できるようになるには，
幾らかの経験が要る．
幸運なことに，捕捉がプログラムにどのような悪影響を及ぼしているのかを考えなくとも，
マクロ定義内の捕捉の起き得るシンボルを判別し，取り除くことができる．
この節では，捕捉可能なシンボルを判別するための直截的な方法を示す．
この章の残りの節では，そのようなシンボルを取り除く方法を説明する．

捕捉可能な変数を定義する規則は幾つかの耳慣れない概念に依存しており，
それらを先に定義しておかなければならない．
\begin{quotation}
フリー：シンボル\verb|s|が式の中でフリーなままで現れるというのは，
その式の中で変数として使われているが，式の中でその変数が束縛されていないときだ．
\end{quotation}
以下の式の中では，
\verb|w|，\verb|x|や\verb|z|はどれも式\verb|list|内でフリーに現れており，
束縛を作っていない．
\begin{verbatim}
(let ((x y) (z 10))
  (list w x z))
\end{verbatim}
しかし外側の式\verb|let|は\verb|x|と\verb|z|に束縛を与えているので，
\verb|let|の中全体では，\verb|y|と\verb|w|のみがフリーなまま現れている．
下の式の中では，
\begin{verbatim}
(let ((x x))
  x)
\end{verbatim}
2個目に現れる\verb|x|はフリーである\wadash
\verb|x|に対して作られた新しい束縛のスコープ内にはない．

\begin{quotation}
骨格：マクロ展開の骨格は，
展開形そのものからマクロ呼び出しの引数の一部だったものを全て取り除いたものだ．
\end{quotation}
以下のように\verb|foo|が定義されていて，
\begin{verbatim}
(defmacro foo (x y)
  `(/ (+ ,x 1) ,y))
\end{verbatim}
下のように呼ばれていたら，
\begin{verbatim}
(foo (- 5 2) 6)
\end{verbatim}
これは下のような展開形を与える．
\begin{verbatim}
(/ (+ (- 5 2) 1) 6)
\end{verbatim}
この展開形の骨格は，上の式の仮引数\verb|x|や\verb|y|が入っていた所に穴を開けたものだ．
\begin{verbatim}
(/ (+                  1) )
\end{verbatim}

これら2つの概念が定義されていれば，
捕捉され得るシンボルを判別するための便利な規則を述べることができる．
\begin{quotation}
捕捉可能：
何らかのマクロの展開形内でシンボルが捕捉可能だというのは，
以下の条件のどちらかが満たされるときである．
(1)マクロ展開の骨格内でフリーなまま現れているか，
(2)マクロに渡された引数が束縛または評価される骨格の一部に束縛されている．
\end{quotation}

幾つかの例からこの規則の表すものを見てみよう．
下のような一番単純な場合では，
\begin{verbatim}
(defmacro cap1 ()
  '(+ x 1))
\end{verbatim}
\verb|x|は骨格内でフリーなまま現れるだろうから，捕捉可能だ．
これが\verb|gripe|内のバグを引き起こしたものだ．
下のマクロでは，
\begin{verbatim}
(defmacro cap2 (var)
  `(let ((x ...)
              (,var ...))
         ...))
\end{verbatim}
\verb|x|は捕捉可能だ．
それは，\verb|x|が束縛されているのと同じ式にマクロ呼び出しの引数も束縛されるからだ．
(それが\verb|for|の失敗を引き起こした．)
同様に以下の2つのマクロでは，
\begin{verbatim}
(defmacro cap3 (var)
  `(let ((x ...))
         (let ((,var ...))
            ...)))

(defmacro cap4 (var)
  `(let ((,var ...))
         (let ((x ...))
            ...)))
\end{verbatim}
どちらでも\verb|x|は捕捉可能だ．
しかし例えば下の場合のように，
\verb|x|の束縛と引数として渡された変数とがともに可視であるようなコンテキストがなければ，
\begin{verbatim}
(defmacro safe1 (var)
  `(progn (let ((x 1))
            (print x))
          (let ((,var 1))
            (print ,var))))
\end{verbatim}
\verb|x|は捕捉可能にはならない．
骨格に束縛されている変数が全て危険な訳ではない．
しかしマクロ呼び出しの引数が骨格によって作られた束縛の中で評価されたら，
\begin{verbatim}
(defmacro cap5 (&body body)
  `(let ((x ...))
         ,@body))
\end{verbatim}
そのように束縛された変数には捕捉の危険がある．
\verb|cap5|の中では，\verb|x|は捕捉可能だ．
しかし次の場合では，
\begin{verbatim}
(defmacro safe2 (expr)
  `(let ((x ,expr))
         (cons x 1)))
\end{verbatim}
\verb|x|は捕捉可能ではない．
\verb|expr|に渡された引数が評価される時点では，\verb|x|の新たな束縛は可視でないからだ．
心配する必要があるのは骨格内の変数の束縛だけだということも気を付けて欲しい．
下のマクロでは，
\begin{verbatim}
(defmacro safe3 (var &body body)
  `(let ((,var ...))
         ,@body))
\end{verbatim}
どのシンボルにも不注意による捕捉の危険はない
（第1引数は束縛されるものと分かっているとして）．

捕捉可能なシンボルを同定する規則を新しく手にした所で，\verb|for|の元の定義を見てみよう．
\begin{verbatim}
(defmacro for ((var start stop) &body body)          ; 誤り
  `(do ((,var ,start (1+ ,var))
             (limit ,stop))
            ((> ,var limit))
         ,@body))
\end{verbatim}
この\verb|for|の定義は，2つの点で捕捉を生み出し得ることが分かる．
まず元の例のように\verb|limit|が\verb|for|の第1引数として渡され得る点だ．
\begin{verbatim}
(for (limit 1 5)
  (princ limit))
\end{verbatim}
しかし\verb|limit|がループ本体内に現れたときも同じ位危険だ．
\begin{verbatim}
(let ((limit 0))
  (for (x 1 10)
        (incf limit x))
  limit)
\end{verbatim}
\verb|for|をこのように使う人は自分の\verb|limit|の束縛がループ内で1ずつ増やされ，
式全体も55を返すものと思っているだろう．
しかし実際には，展開形の骨格に生成された\verb|limit|の束縛だけが1ずつ増やされる．
\begin{verbatim}
(do ((x 1 (1+ x))
     (limit 10))
  ((> x limit))
  (incf limit x))
\end{verbatim}
そしてそれが反復を制御する役目を持っているので，反復は終了さえしない．

この章で提示された規則は，あくまでも目安として意図されているという留保の元で使って欲しい．
それらは形式に則って述べられてさえいないし，ましてや形式上正しくもない．
捕捉が問題になるのは元々の意図によることなので，定義は曖昧だ．
例えば下のような式では，
\begin{verbatim}
(let ((x 1)) (list x))
\end{verbatim}
\verb|(list x)|が評価されたときに\verb|x|が新しい変数を参照することは，エラーとは見なさない．
\verb|let|にはそのような動作が期待されている．
変数捕捉を判別する規則もやはり厳密ではない．
上の3個のテストを満たしながら，なお意図しない変数捕捉を引き起こし得るようなマクロが書ける．
例えば下のようなマクロだ．
\begin{verbatim}
(defmacro pathological (&body body)                 ; 誤り
  (let* ((syms (remove-if (complement #'symbolp)
                          (flatten body)))
         (var (nth (random (length syms))
                   syms)))
    `(let ((,var 99))
       ,@body)))
\end{verbatim}
このマクロが呼ばれると，
本体内の式は\verb|progn|の中にあるかのように評価される\wadash
しかし本体内のランダムなどれか1個の変数が違った値を持つかもしれない．
これは明らかに変数捕捉だが，その変数は骨格内にはないので，上の規則を満たしている．
しかし実践の場では，上の規則はほぼ必ず機能するだろう．
上の例のようなマクロを書きたいときは（あったとしても）めったにない．
%}}}
\subsection{適切な名前によって捕捉を避ける}   %{{{
第1, 2節では変数捕捉の実例を2種類に分けた：
引数の捕捉，
これは引数内で使われたシンボルがマクロの骨格に生成された束縛に捕まるものだ．
そしてフリー変数の捕捉，
これはマクロの展開形内のフリーなシンボルが，
マクロが展開された場所で効力を持つ束縛に捕捉されるものだ．
普通，後者は単にグローバル変数に区別の付くような名前を与えることで解決される．
Common Lispのグローバル変数には，先頭と末尾にアスタリスクが付く名前を付けるのが伝統だ．
例えばカレント・パッケージを定義する変数は\verb|*package*|と名付けられる．
(このような名前は，普通の変数でないことを強調するために
「スター・パッケージ・スター」と発音されることがある．)

だからただの\verb|w|ではなく，
\verb|*warnings*|等の名前の変数に警告を蓄えるようにすることは，
完全に\verb|gripe|の作者の責任だった．
\verb|sample-ratio|の作者が\verb|*warnings*|を仮引数の名前に使っていたら，
現れるバグというバグはみな自分の責任だろう．
しかし仮引数を\verb|w|という名前にしても安全だろうと考えた点は責められることではない．
%}}}
\subsection{優先評価によって捕捉を避ける}   %{{{
危険のある引数をマクロ展開によって作られる束縛よりも外で評価することだけで，
引数の捕捉が回避できることがある．
一番単純なものはマクロを式\verb|let|から始めることで回避できる．
第\ref{fig:AvoidCaptureWithLet}図にはマクロ\verb|before|の2通りの定義を示したが，
これは2個のオブジェクトと1個のシーケンスを引数に取り，
そのシーケンス内で1個目のオブジェクトが2個目より前に現れるときに真を返すものだ
\footnote{このマクロは例として使われているに過ぎない．
本当はマクロとして実装すべきでもないし，こんな非効率的なアルゴリズムを使うべきでもない．
適切な定義はfangページを参照．}．

\begin{figure}\begin{center}
\fbox{~\,\begin{minipage}{\FrameWidth}\narrowbaselines
\vspace{3pt}\hspace{12zw}捕捉を起こしやすい：
\begin{center}\begin{minipage}{240pt}\texttt{%
(defmacro before (x y seq)\\
~~`(let ((seq ,seq))\\
~~~~~(< (position ,x seq)\\
~~~~~~~(position ,y seq))))}\end{minipage}\end{center}
\hspace{12zw}正しいヴァージョン：
\begin{center}\begin{minipage}{240pt}\texttt{%
(defmacro before (x y seq)\\
~~~`(let ((xval ,x) (yval ,y) (seq ,seq))\\
~~~~~~(< (position xval seq)\\
~~~~~~~~(position yval seq))))\\
}\end{minipage}\end{center}
\vspace{1.3em}\end{minipage}~\,}\end{center}
\caption{\texttt{let}による変数捕捉の回避方法．}
\label{fig:AvoidCaptureWithLet}
\end{figure}

1個目の定義は不適切だ．
最初の\verb|let|は\verb|seq|に渡された式が確かに1回だけ評価されるようにしているが、
これでは次のような問題を防ぐのに不十分だ。
\begin{verbatim}
> (before (progn (setq seq '(b a)) 'a)
          'b
          '(a b))
NIL
\end{verbatim}
これは結局「\verb|(a b)|の中で\verb|a|は\verb|b|より前にあるだろうか？」と尋ねているわけだ．
適切に作られた\verb|before|ならば真を返すところだ。
マクロ展開を見ると実際に何が起きるかが分かる．
\verb|<|の第1引数の評価が第2引数内でも使われるリストを並べ替えてしまっている．
\begin{verbatim}
(let ((seq '(a b)))
  (< (position (progn (setq seq '(b a)) 'a)
               seq)
     (position 'b seq)))
\end{verbatim}
この問題を回避するには，引数を全て1個の大きな\verb|let|で最初に評価してしまえば十分だ．
そのため第\ref{fig:AvoidCaptureWithLet}図内の2番目の定義には捕捉の危険はない．

残念なことに，\verb|let|を使う技が通用する状況は多くない．
\begin{enumerate}
\item 捕捉の危険のある引数はきっかり1回だけ評価されるべきで，
\item マクロ骨格に生成された束縛のスコープ内ではどの引数も評価の必要はない，
\end{enumerate}
というマクロでしか使えない．
この制限は多数のマクロを切り捨ててしまう．
前に提案されたマクロ\verb|for|はどちらの条件も満たさない．
しかしこの手法の変形を使うことで，\verb|for|のようなマクロから捕捉の危険を取り除くことができる．
ローカルに生成されたどの束縛よりも外側の$\lambda$式の中に実行本体となる式を包み込んでしまうのだ．

反復用マクロを含む幾つかのマクロは，
マクロ呼出しに現れる式が新しく生成された束縛の中で評価されるような式を生成する．
例えば\verb|for|の定義内では，
繰り返しの本体はマクロの作った\verb|do|の中で評価されなければならない．
そのため，繰り返し本体内に出て来る変数は\verb|do|に生成された束縛による捕捉の危険がある．

繰り返し本体内の変数をそのような捕捉から保護するためには，
本体をクロージャで包み，さらに繰り返しを行う際に，
式そのものを挿入せずにクロージャを\verb|funcall|で呼べばよい．

第\ref{fig:AvoidCaptureWithClosure}図にはこの技法を用いたヴァージョンの\verb|for|を示した．
クロージャは\verb|for|の展開形の中で最初に作られるので，
繰り返し本体内に現れるフリーシンボルは全てマクロを呼んでいる環境内の変数を参照する．
これなら\verb|do|はクロージャの仮引数を通じてその本体と関わり合うことになる．
全てのクロージャは現在が繰り返しの何回目かを\verb|do|から伝えられる必要があるので，
ただ1個の仮引数（マクロ呼び出しでインデックスに指定したシンボル）を持つ．

\begin{figure}\begin{center}
\fbox{~\,\begin{minipage}{\FrameWidth}\narrowbaselines
\vspace{3pt}\hspace{12zw}捕捉を起こしやすい：
\begin{center}\begin{minipage}{240pt}\texttt{(defmacro for ((var start stop) \&body body)\\
~~`(do ((,var ,start (1+ ,var))\\
~~~~~~~~(limit ,stop))\\
~~~~~((> ,var limit))\\
~~~~~,@body))}\end{minipage}\end{center}
\hspace{12zw}正しいヴァージョン：
\begin{center}\begin{minipage}{240pt}\texttt{(defmacro for ((var start stop) \&body body)\\
~~~`(do ((b \#'(lambda (,var) ,@body))\\
~~~~~~~~~(count ,start (1+ count))\\
~~~~~~~~~(limit ,stop))\\
~~~~~~~~((> count limit))\\
~~~~~~(funcall b count)))\\
}\end{minipage}\end{center}
\vspace{1.3em}\end{minipage}~\,}\end{center}
\caption{クロージャによる変数捕捉の回避方法．}
\label{fig:AvoidCaptureWithClosure}
\end{figure}

式を$\lambda$式で包む技法は普遍的な対処法ではない．
これはコード本体の保護には使えるが，例えば（最初の不適切な\verb|for|のように）
同じ変数が同じ\verb|let|や\verb|do|に2回束縛される危険があるような場合には，
クロージャは何の役にも立たない．
幸運なことにこの場合は，本体をクロージャ内に包むように\verb|for|を書き直したことで，
\verb|do|が引数\verb|var|のために束縛を生成する必要がなくなっている．
元の\verb|for|の引数\verb|var|はクロージャの仮引数になっており，
\verb|do|内では実際のシンボル\verb|count|で置き換えてもよい．
よって第9.3節のテストでも分かるように，
\verb|for|の新しい定義は変数捕捉の危険を完全に克服している．

クロージャを使うことの短所は，やや非効率的になるかも知れないことだ．
関数呼び出しを1回余計に増やしたことになったかも知れない．
事に依るともっと不都合なことに，
コンパイラがクロージャにダイナミックエクステントを与えていなければ，
そのためのスペースは実行時にヒープ領域に割り当てる必要が出るかもしれない．
%}}}
\subsection{Gensymによって捕捉を避ける}   %{{{
マクロの変数捕捉を避けるには，確実な方法が1つある．
捕捉され得るシンボルをgensymで置き換えてしまうのだ．
\verb|for|の元のヴァージョンでは，
問題は2個のシンボルが不注意から同じ名前を持ってしまったときに起きた．
マクロ骨格が呼出側コードでも使われている名前を含むという可能性を回避したいなら，
マクロ定義内では変な名前のシンボルだけを使うことで対処が望めるかも知れない：
\begin{verbatim}
(defmacro for ((var start stop) &body body)              ; 誤り
  `(do ((,var ,start (1+ ,var))
        (xsf2jsh ,stop))
     ((> ,var xsf2jsh))
     ,@body))
\end{verbatim}
しかしこれは解決策とはとても言えない．
これはバグを取り除いたのではなく，表面化しにくいようにしただけだ．
それも大して表面化しにくいわけではない\wadash
同じマクロを入れ子にして使ったときに起きる衝突がやはり想定できる．

シンボルが一意的であることを保証する方法が必要だ．
Common Lispの関数\verb|gensym|は，まさにこのために存在する．
この関数はgensymと呼ばれるシンボルを返すが，
これはコードに打ち込まれたりプログラムに生成されたどのシンボルとも
\verb|eq|ではないことが保証されている．

Lispシステムはどうやってそれを保証するのだろうか？
Common Lispの全てのパッケージは，その中で認識されている全てのシンボルのリストを保持している．
(パッケージへの導入に付いては，chuanページを参照．)
そのリストに載っているシンボルはパッケージにインターンされていると言われる．
\verb|gensym|を呼び出す度に，一意でインターンされていないシンボルが返される．
そして\verb|read|に読み取られるシンボルは全てインターンされるので，
gensymと等しいものを打ち込むことはできない．
そのため，次のように始まる式は，
\begin{verbatim}
   (eq (gensym) ...
\end{verbatim}
何を続けても真を返すようにすることはできない．

\verb|gensym|にシンボルを生成させることは，
奇妙な名前のシンボルを選ぶ手法を一歩進めたようなものだ\wadash
gensymは，電話帳を探しても載っていないような名前のシンボルを返す．
Lispがgensymを表示しなければならないときは，次のようにする．
\begin{verbatim}
> (gensym)
#:G47
\end{verbatim}
表示されるものはLispにとって「名無の権兵衛」程のものに過ぎない．
これは任意の名前で，名前が意味を持つことがないように作られたものだ．
そしてこの表示について余計な想像を一切引き起こさないように，
gensymsはシャープ・コロンに続いて表示される．
これは特殊なリードマクロで，
表示されたgensymを再び読み込もうとしたときエラーを起こすためだけに存在している．

\begin{figure}\begin{center}
\fbox{~\,\begin{minipage}{\FrameWidth}\narrowbaselines
\vspace{3pt}\hspace{12zw}捕捉を起こしやすい：
\begin{center}\begin{minipage}{240pt}\texttt{%
(defmacro for ((var start stop) \&body body)\\
~~`(do ((,var ,start (1+ ,var))\\
~~~~~~~~(limit ,stop))\\
~~~~~((> ,var limit))\\
~~~~~,@body))%
}\end{minipage}\end{center}
\hspace{12zw}正しいヴァージョン：
\begin{center}\begin{minipage}{240pt}\texttt{%
(defmacro for ((var start stop) \&body body)\\
~~(let ((gstop (gensym)))\\
~~~~`(do ((,var ,start (1+ ,var))\\
~~~~~~~~~~(,gstop ,stop))\\
~~~~~~~~~((> ,var ,gstop))\\
~~~~~~~,@body)))\\
}\end{minipage}\end{center}
\vspace{1.3em}\end{minipage}~\,}\end{center}
\caption{Gensymによる変数捕捉の回避方法．}
\label{fig:AvoidCaptureWithGensym}
\end{figure}

\texttt{CLtL2}に従うCommon Lispでは，
gensymの印字表現に現れる数は\verb|*gensym-counter*|から来ている．
これは常に整数に束縛されているグローバル変数だ．
このカウンタを手動で設定することで2個のgensymを同じように表示させることができる．
\begin{verbatim}
> (setq x (gensym))
#:G48
> (setq *gensym-counter* 48 y (gensym))
#:G48
>(eqxy)
NIL
\end{verbatim}
しかしこれらは同一ではない．

第\ref{fig:AvoidCaptureWithGensym}図には，gensymを使った\verb|for|の正しい定義を載せた．
マクロに渡された式の中のシンボルと衝突を起こしていた\verb|limit|はもうない．
それはマクロ展開の時点で生成されたシンボルに置き換わってしまう．
マクロが展開される度，
\verb|limit|の場所には展開時に生成された一意な名前のシンボルが代わりに置かれる．

\verb|for|の正しい定義は一発で書き上げるには複雑過ぎる．
完成品のコードは，完成した数学定理のように，
しばしば多くの試行錯誤を覆い隠している．
だからあるマクロを何段階にも分けて書かなくてはならなくても心配しないことだ．
\verb|for|のようなマクロを書き始めるには，
最初のヴァージョンは変数捕捉について考えずに書き，
そうしたら前に戻って変数捕捉に関わるシンボルをgensymで置き換えるのがいいかも知れない．
%}}}
\subsection{パッケージによって捕捉を避ける}   %{{{
ある程度までは，マクロを独自のパッケージに入れることで変数捕捉を避けることができる．
パッケージ\verb|macros|を作ってその中で\verb|for|を定義すれば，最初に挙げた定義
\begin{verbatim}
(defmacro for ((var start stop) &body body)
     `(do ((,var ,start (1+ ,var))
             (limit ,stop))
            ((> ,var limit))
         ,@body))
\end{verbatim}
を使っても他のパッケージからは安全に呼び出せる．
\verb|for|を別のパッケージ（例えば\verb|mycode|）から呼ぶと，
第1引数に\verb|limit|を使っても，それは\verb|mycode::limit|になる\wadash
これはマクロ骨格に現れる\verb|macros::limit|とは別物だ．

しかしパッケージは変数捕捉の問題の一般的な解決策にはならない．
第1には，マクロはあるプログラムに統合された一部分であって，
それらを独自のパッケージ内に分けておかなければならないのでは不便だ．
第2には，パッケージ\verb|macros|内の別のコードに対する保護には全くなっていない．
%}}}
\subsection{異なる名前空間での捕捉}   %{{{
これまでの章ではあたかも捕捉が変数のみに悪さをする問題かのように扱ってきた．
確かにほとんどの捕捉は変数捕捉だが，
Common Lispの他の名前空間においても同様に問題が起き得る．

関数もローカルな束縛を持つことができ，そして関数の束縛も同様に不用意な捕捉を引き起こす可能性がある．
例：
\begin{verbatim}
> (defun fn (x) (+ x 1))
FN
> (defmacro mac (x) `(fn ,x))
MAC
> (mac 10)
11
> (labels ((fn (y) (- y 1)))
    (mac 10))
9
\end{verbatim}
捕捉を見つける規則から予測できるように，
\verb|mac|の骨格内でフリーなまま使われている\verb|fn|には捕捉の危険がある．
\verb|fn|がローカルに再束縛されると，\verb|mac|の返す値は普通とは違ったものになる．

これにはどう対処すればよいだろうか？
捕捉の危険のあるシンボルが組込みの関数やマクロの名前ならば，何もしないでおくのが理に適っている．
\CLtL2によれば(p. 260)，
組込みのものの名前がローカル関数またはマクロに束縛されたとき，「結果は定義されない」．
だから書いたマクロの動作の問題ではない．
組込み関数を再束縛したら，自分のマクロだけでなく様々な問題に悩まされることになるだろう．

そうでないとき，変数名を保護するのと同じ方法で関数名をマクロ引数の捕捉から保護できる．
マクロ骨格によってローカルに定義されたどのような関数にも，gensymを関数名に使うことだ．
この場合，フリーなシンボルの捕捉を避けることは少し難しくなる．
変数をフリーシンボル捕捉から保護するには，はっきり区別できるグローバル変数用の名前を付ければよかった：
例えば\verb|w|でなく\verb|*warnings*|を使えばよい．
しかしこの解決策は関数には有効ではない．
グローバル関数を区別するための命名法には慣習が無いからだ\wadash
何しろ大部分の関数がグローバルなのだから．
マクロが，必要な関数がローカルに再定義されているかもしれない環境内で呼ばれることが心配なら，
最良の解決策は，おそらくコードを独立したパッケージに入れることだ．

ブロック名，すなわち\verb|go|や\verb|throw|で使われるタグからもやはり捕捉が起こり得る．
マクロにそのような名前のシンボルが必要なら，\verb|our-do|の定義と同様にgensymを使うべきだ．

また\verb|do|等のオペレータは暗黙のうちに\verb|nil|という名のブロックに囲まれることも忘れてはいけない．
そのため\verb|do|の中の\verb|return|や\verb|return-from nil|は，
\verb|do|の中の式ではなく\verb|do|そのものから制御を戻すことになる．
\begin{verbatim}
> (block nil
         (list 'a
               (do ((x 1 (1+ x)))
                 (nil)
                 (if (> x 5)
                   (return-from nil x)
                   (princ x)))))
12345
(A 6)
\end{verbatim}
\verb|do|が\verb|nil|という名前のブロックを作っていなかったら，
この例は\verb|(A 6)|でなくただの\verb|6|を返していたはずだ．

\verb|do|の暗黙のブロックは問題とは言えない．
\verb|do|はそのように振る舞うことになっているからだ．
しかし展開形が\verb|do|を含むようなマクロを書いたときは，
それらがブロック名\verb|nil|を捕捉してしまうことは覚えておくべきだ．
\verb|for|のようなマクロでは，
\verb|return|や\verb|return-from nil|は，外側のブロックではなく\verb|for|から制御を戻すことになる．
%}}}
\subsection{変数捕捉にこだわる理由}   %{{{
これまで示した例には極めて病的と言っていいものもあった．
それらを見て，こう言いたくなった人もいるかもしれない．
「変数捕捉なんて滅多に起きるもんじゃない，なんで気に病まなきゃいけないんだ？」
この問には2通りの答え方がある．
1つ目は別の質問を返すことだ：
バグのないプログラムが書けるのに，どうして少々のバグを持ったプログラムを書くのですか？

長い答え方は，実際の応用では
書いたコードの用途について予測を立てるのは危険だと指摘することだ．
全てのLispプログラムは，現在「オープン・アーキテクチャ」と呼ばれる構造を持つ．
他人の使うコードを書いているのなら，
その人達は予測もつかない方法でそれを使うかも知れない．
また，心配しなければならないのは他人だけではない．
プログラムもプログラムを書くのだ．
\begin{verbatim}
(before (progn (setq seq '(b a)) 'a)
        'b
        '(a b))
\end{verbatim}
このようなコードを書く人間はいないかもしれないが，
プログラムに生成されたコードはしばしばこのような形をしている．
個々のマクロが単純で理に適った外見の展開形を生成するときでさえ，
マクロ呼び出しにマクロ呼び出しを渡したりすれば，
途端に展開形はいかにも人が書いたものには見えない大きなプログラムになり得る．
そのような場合は，マクロが誤って展開されてしまう状況に対しては，
それがどんなにありそうもないものでも，防御策を取っておいて損はない．

最後に言いたいのは，捕捉を避けるのはそれ程難しくはないということだ．
少し経てば習慣になってしまう．
Common Lispの古典的な\verb|defmacro|は料理人の包丁のようなものだ．
エレガントな道具で危険にも思えるが，達人は確信を持って使っている．
%}}}
%}}}
\section{マクロのその他の落し穴} %{{{
マクロを書くときには注意が余分に必要だ．
関数は自分のレキシカルな領域に孤立しているが，
マクロは，呼出側のコード内に展開されるので，
注意深く書かないと不愉快な驚きをもたらすことがある．
第9章で扱った変数捕捉はその最たるものだ．
この章ではマクロを定義する際に避けるべき問題をさらに議論する．
\subsection{評価の回数}   %{{{
前の章では\verb|for|の不適切な定義例をいくつか示した．
第\ref{fig:ControlingArgEval}図にはさらに2例を，比較用の適切な定義と共に示した．

\begin{figure}\begin{center}
\fbox{~\,\begin{minipage}{\FrameWidth}\narrowbaselines
\vspace{3pt}\hspace{12zw}適切なヴァージョン：
\begin{center}\begin{minipage}{240pt}\texttt{%
(defmacro for ((var start stop) \&body body)\\
~~(let ((gstop (gensym)))\\
~~~~`(do ((,var ,start (1+ ,var))\\
~~~~~~~~~~(,gstop ,stop))\\
~~~~~~~~~((> ,var ,gstop))\\
~~~~~~~,@body)))\\
}\end{minipage}\end{center}
\hspace{12zw}複数回の評価を起こし得る：
\begin{center}\begin{minipage}{240pt}\texttt{%
(defmacro for ((var start stop) \&body body)\\
~~`(do ((,var ,start (1+ ,var)))\\
~~~~~~~((> ,var ,stop))\\
~~~~~,@body))\\
}\end{minipage}\end{center}
\hspace{12zw}評価の順番が間違っている：
\begin{center}\begin{minipage}{240pt}\texttt{%
(defmacro for ((var start stop) \&body body)\\
~~(let ((gstop (gensym)))\\
~~~~`(do ((,gstop ,stop)\\
~~~~~~~~~~(,var ,start (1+ ,var)))\\
~~~~~~~~~((> ,var ,gstop))\\
~~~~~~~,@body)))\\
}\end{minipage}\end{center}
\vspace{1.3em}\end{minipage}~\,}\end{center}
\caption{引数評価の制御}
\label{fig:ControlingArgEval}
\end{figure}

捕捉を起こすことはないが，2番目にはバグがある．
これの展開形は\verb|stop|として渡された式を反復の度に評価してしまう．
一番運のよかった場合でも，この種のマクロは非効率で，1回行えばよいことを繰り返している．
\verb|stop|に副作用があれば，このマクロが実際に間違った結果をもたらすかも知れない．
例えば次のループはいつまでも終了しない．
ゴールが反復の度に遠のいてゆくからだ．
\begin{verbatim}
> (let ((x 2))
     (for (i 1 (incf x))
        (princ i)))
12345678910111213...
\end{verbatim}

\verb|for|のようなマクロを書くときには，
マクロの引数は式であって値ではないことを忘れてはいけない．
それらが展開形内に現れる場所によっては複数回評価されることもある．
上の場合，解決策は式\verb|stop|が返した値に変数を束縛し，
繰り返しの間にはその変数を参照することだ．

マクロは，明確に反復を意図していなければ，
式がきっかりマクロ呼び出しに出て来る回数だけ評価されるようにしておくべきだ．
この規則の当てはまらない明らかな例がある：
Common Lispの\verb|or|は，全ての引数を必ず評価するようになったら
ずっと不便になってしまうだろう（それではPascalの\verb|or|構文だ）．
しかしこのような場合では何回評価が行われるかは分かっている．
上の2番目の\verb|for|ではそうではない．
式\verb|stop|が複数回評価されると想定するような理由はないし，実際そうであるべき理由もない．
2番目の\verb|for|のようにして書かれたマクロは過誤の産物であることが一番多い．

意図せぬ複数回の評価は\verb|setf|の上に構築されたマクロにとっては特に難しい問題だ．
Common Lispはそのようなマクロを書き易くするための幾つかのユーティリティを提供している．
問題と解決策は第12章で扱う．
%}}}
\subsection{評価の順番}   %{{{
式が評価される順番は式が評価される回数程重要ではないが，時々問題になる．
Common Lispの関数呼び出しでは，引数は左から右の順で評価される．
\begin{verbatim}
> (setq x 10)
10
> (+ (setq x 3) x)
6
\end{verbatim}
マクロについてもそうするのがよい習慣だ．
マクロでは常に確かに式がマクロ呼び出し内と同じ順で評価されるようにするべきだ．

第\ref{fig:ControlingArgEval}図では，3番目の\verb|for|にも微妙なバグがある．
仮引数\verb|stop|は\verb|start|より前に評価される．
マクロ呼び出しでは逆の順番になっているというのに．
\begin{verbatim}
> (let ((x 1))
    (for (i x (setq x 13))
         (princ i)))
13
NIL
\end{verbatim}
このマクロは，時間が逆戻りしたかのようなdisconcerting印象を与える．
字面の上では式\verb|start|が最初に出て来るにも関わらず，
式\verb|stop|の評価が式\verb|start|の返す値に影響しているのだ．

適切に定義された\verb|for|では，引数は確かに出て来る順で評価されるようになっている．
\begin{verbatim}
> (let ((x 1))
    (for (i x (setq x 13))
         (princ i)))
12345678910111213
NIL
\end{verbatim}
これなら\verb|x|を式\verb|stop|内で設定しても，前の引数が返す値には何の影響もない．

上に示した例はこのために作ったものだが，
この種の問題が顕在化する状況は存在し，そしてこのようなバグは発見が極めて難しい．
マクロのある引数の評価が別の引数が返す値に影響するようなコードを書く人はまずいないだろう．
しかし人は意図的には決してやらないことでも誤ってやってしまうことがあるものだ．
ユーティリティは，意図された通りに使われれば正しく機能するだけでなく，
バグを隠蔽してもいけない．
上の例のようなコードを書く人がいたら，それはきっと間違って書いたのだろう．
しかし適切に定義された\verb|for|は容易に誤りに気付かせてくれる．
%}}}
\subsection{関数によらないマクロ展開}   %{{{
Lispは，マクロ展開を生成するコードは
第3章で論じた意味で純粋に関数的であるものと予期している．
展開を行うコードは引数として渡された式にのみ依存すべきで，
値を返す他には周囲の世界に影響しようとすべきではない．

\textsf{CLtL2}にもあるように(p. 685)，
コンパイル済みコード内でのマクロ呼び出しは
実行時に再展開されることはないと思っておくのが安全だ．
そうでなければ，Common Lispはいつの時点で，
またはどれほどの頻度でマクロ呼び出しが展開されるのか保証できなくなってしまう．
マクロの展開結果がそのどちらかによって変わることがあれば，それは誤りと見なされる．
例えば，あるマクロが使われた回数を数えたいとしよう．
単にソースに検索をかければよい訳ではない．
そのマクロがプログラムの生成したコード内で呼ばれているかも知れないからだ．
だから次のようなマクロを定義したくなる．
\begin{verbatim}
(defmacro nil! (x)                   ; 誤り
  (incf *nil!s*)
  `(setf ,x nil))
\end{verbatim}
この定義ではグローバル変数\verb|*nil!s*|が\verb|nil!|が展開される度に1だけ増加する．
しかしこの変数の値から\verb|nil!|の呼ばれた回数が分かると思ったら間違いだ．
あるマクロ呼び出しは複数回展開され得る（実際しばしばそうだ）．
例えばソースコードの変換を行うプリプロセッサは，式内のマクロ呼び出しを，
それを変換すべきかどうか判断する前に展開しなければならないかもしれない．

一般則としては，展開を行うコードは引数以外の何にも依存すべきでない．
だから例えば展開形を文字列から作り出すようなどのマクロも，
展開時に何のパッケージ内にいるかについて勝手に予想しないよう注意すべきだ．
次の簡潔だがかなり病的な例は，
\begin{verbatim}
(defmacro string-call (opstring &rest args)              ; 誤り
     `(,(intern opstring) ,@args))
\end{verbatim}
オペレータの印字名をとってそのオペレータへの呼び出しを展開するマクロを定義している．
\begin{verbatim}
> (defun our+ (x y) (+ x y))
OUR+
> (string-call "OUR+" 2 3)
5
\end{verbatim}
\verb|intern|は文字列を取り，対応するシンボルを返す．
しかしオプショナル引数のパッケージを省くと，カレント・パッケージが使われる．
よって展開形はそれが生成されるときのパッケージに依存することになる．
\verb|our+|がそのパッケージで可視でない限り，展開形は未定義関数への呼び出しになる．

MillerとBensonの\emph{Lisp Style and Design}は
展開コードの副作用から起きる問題の特別に汚い例に言及している．
Common Lispでは\textsf{CLtL2}にもあるように(p. 78)，
\verb|&rest|引数に束縛されたリストが新しく生成されたものである保証はない．
それはプログラム内のどこかのリストと構造を共有しているかも知れない．
その結果，\verb|&rest|引数は破壊的に操作してはいけないことになる．
同時に他の何に変更を加えているか分からないからだ．

この可能性は関数とマクロ両方に影響する．
関数については\verb|apply|を使うと問題が顕在化する．
Common Lispの規格に沿った処理系の実装では次の問題が起こり得るのだ．
引数のリストの末尾にet alを付け加える関数\verb|et-al|を定義したいとしよう．
\begin{verbatim}
(defun et-al (&rest args)
  (nconc args (list 'et 'al)))
\end{verbatim}
この関数は普通に呼ぶ限りでは適切に動作するように思える：
\begin{verbatim}
> (et-al 'smith 'jones)
(SMITH JONES ET AL)
\end{verbatim}
しかしそれを\verb|apply|経由で呼び出すと，既存のデータ構造が変更される可能性がある：
\begin{verbatim}
> (setq greats '(leonardo michelangelo))
(LEONARDO MICHELANGELO)
> (apply #'et-al greats)
(LEONARDO MICHELANGELO ET AL)
> greats
(LEONARDO MICHELANGELO ET AL)
\end{verbatim}
少なくともCommon Lispの規格に沿った処理系ではこうなる可能性がある．
今のところ実際にはそのような処理系はないようだが．

マクロでは危険度が大きい．
\verb|&rest|引数に変更を加えるマクロはそれによってマクロ呼び出しに変更を加える可能性がある．
言い替えれば，うっかり自己修正的なプログラムができてしまいかねないということだ．
現実的な危険性もある\wadash
これは既存の処理系で起こったことなのだ．
何かを\verb|&rest|引数に\verb|nconc|するマクロを書き
\footnote{\texttt{`',(foo)}は\texttt{`(quote ,(foo))}と等価な表現だ．}，
\begin{verbatim}
(defmacro echo (&rest args)
  `',(nconc args (list 'amen)))
\end{verbatim}
次にそれを呼び出す関数を書く：
\begin{verbatim}
(defun foo () (echo x))
\end{verbatim}
広く使われているCommon Lisp処理系では，次のような結果になる．
\begin{verbatim}
> (foo)
(X AMEN AMEN)
> (foo)
(X AMEN AMEN AMEN)
\end{verbatim}
\verb|foo|は誤った結果を返すだけでなく，実行する度に結果は異なる．
マクロが展開される度に\verb|foo|の定義が変更されているからだ．

あるマクロ呼び出しが複数回展開されることについて先に論じた点についても，
この例から分かることがある．
この特定の処理系では，\verb|foo|の1回目の呼び出しは2個のamenから成るリストを返す．
何かの理由でこの処理系はマクロ呼び出しを\verb|foo|の展開時に1回展開し，
そしてその後呼び出される度にも1回ずつ展開したのだ．

\verb|echo|は次のように定義した方が安全だ．
\begin{verbatim}
(defmacro echo (&rest args)
  `'(,@args amen))
\end{verbatim}
これはコンマ・アットは\verb|nconc|でなく\verb|append|と等価だからだ．
このマクロを再定義した後は，
\verb|foo|はコンパイルされていなくとも再定義しなければならない．
前のヴァージョンの\verb|echo|がそれを書き換えてしまったからだ．
??? ここから??ENDまでの行が挿入か削除されたようです

マクロでは，同様の危険があるのは\verb|&rest|引数だけではない．
リストであるマクロの引数はいずれも変更しないでおくべきだ．
引数のどれかに変更を加えるマクロとそれを呼ぶ関数を定義すると，
\begin{verbatim}
(defmacro crazy (expr) (nconc expr (list t)))

(defun foo () (crazy (list)))
\end{verbatim}
呼出側関数のソースコードは変更されてしまう可能性がある．
ある処理系では1回目に呼び出したときにそうなった．
\begin{verbatim}
> (foo)
(T T)
\end{verbatim}
これはコンパイラとインタプリタ両方で起きたことだ．

要するに，引数のリスト構造を破壊的に変更することでコンシングを避けようとしないことだ．
出来上がったプログラムは，例え動作したとしても可搬性を持たないだろう．
可変個の引数を取る関数内でコンシングを避けたいなら，
解決策の一つはマクロを使い，コンシングをコンパイル時にずらす方法だ．
マクロをこのように使うことについては，第13章を参照すること．

またマクロ展開を行うコードの返した式がクォート付きリストを含むときは，
それに破壊的操作を行うことも避けるべきだ．
これはマクロの本質的な制限ではなく，第3.3節で大まかに触れた原則の一例だ．
%}}}
\subsection{再帰}   %{ {{
関数を再帰的に定義するのが自然なときがある．
次のような関数は，本質的に再帰的な性質を持っている．
\begin{verbatim}
(defun our-length (x)
  (if (null x)
    0(1+ (our-length (cdr x)))))
\end{verbatim}
上の定義は，等価な反復版よりも（おそらく遅いだろうが）自然に思える．
\begin{verbatim}
(defun our-length (x)
  (do ((len 0 (1+ len))
       (y x (cdr y)))
    ((null y) len)))
\end{verbatim}

再帰的でもなく，相互再帰的な関数の集合の一部でもない関数は，
第7.10章で述べた簡単な方法によりマクロに変換できる．
しかしただ逆クォートとコンマを挿入するだけでは再帰的関数は変換できない．
組込み関数\verb|nth|を例に取ってみよう．
(話を簡単にするため，この\verb|nth|はエラーチェックをしないものとする．)
第\ref{fig:MistakenRecursiveFunc}図には
\verb|nth|をマクロとして定義しようとして間違えた例を示した．
表面的には\verb|nthb|は\verb|ntha|と等価に見えるが，
\verb|nthb|を使ったコードはコンパイルに通らない．
これはマクロ呼び出しの展開が終了しないためだ．

\begin{figure}\begin{center}
\fbox{~\,\begin{minipage}{\FrameWidth}\narrowbaselines
\vspace{3pt}\hspace{12zw}正しく動作するもの：
\begin{center}\begin{minipage}{240pt}\texttt{%
(defun ntha (n lst)\\
~~(if (= n 0)\\
~~~~~~(car lst)\\
~~~~~~(ntha (- n 1) (cdr lst))))%
}\end{minipage}\end{center}
\hspace{12zw}コンパイルできないもの：
\begin{center}\begin{minipage}{240pt}\texttt{%
(defmacro nthb (n lst)\\
~~`(if (= ,n 0)\\
~~~~~~~(car ,lst)\\
~~~~~~~(nthb (- ,n 1) (cdr ,lst))))\\
}\end{minipage}\end{center}
\vspace{1.3em}\end{minipage}~\,}\end{center}
\caption{誤って再帰関数と同じように捉えてしまった例．}
\label{fig:MistakenRecursiveFunc}
\end{figure}

一般的に，マクロが他のマクロへの参照を含むことは，展開がどこかで終了する限りは問題ない．
\verb|nthb|の問題は，\verb|nthb|のどの展開形も\verb|nthb|自身への参照を含む点だ．
関数版の\verb|ntha|は終了する．
それは\verb|n|の値について再帰的なのだが，この値は再帰の度に減少するからだ．
しかしマクロ展開は式にしかアクセスがなく，その値までは分からない．
コンパイラが，例えば\verb|(nthb x y)|を展開しようとすると，最初の展開では
\begin{verbatim}
(if (= x 0)
  (car y)
  (nthb (- x 1) (cdr y)))
\end{verbatim}
が作られ，これは更に次のようになる．
\begin{verbatim}
(if (= x 0)
  (car y)
  (if (= (- x 1) 0)
    (car (cdr y))
    (nthb (- (- x 1) 1) (cdr (cdr y)))))
\end{verbatim}
こうして無限ループに陥ってしまうのだ．
マクロが自分自身の呼び出しを展開することに問題はないが，
それはいつまでも続かないときの話だ．

\verb|nthb|のような再帰的マクロの危険な点は，インタプリタでは適切に機能することだ．
とうとう動作するようになったプログラムをコンパイルしようとしたとき，
それがコンパイルを通りすらしないことになる．
それだけでなく，問題が再帰的マクロによることは普通分からない．
コンパイラはただ無限ループに陥り，そこで何が悪いのか考える羽目になる．

上の場合，\verb|ntha|は末尾再帰的だ．
末尾再帰的関数は容易に反復形に変換でき，それはマクロのモデルに使える．
\verb|nthb|のようなマクロはこうして書ける．
\begin{verbatim}
(defmacro nthc (n lst)
  `(do ((n2 ,n (1- n2))
        (lst2 ,lst (cdr lst2)))
     ((= n2 0) (car lst2))))
\end{verbatim}
原則的にはマクロで再帰関数を複製することは不可能ではない．
しかし複雑な再帰関数の変換は難しかったり，不可能ですらあるときもある．

マクロの用途によっては，代わりにマクロと関数の組合せを使うことで十分なときもある．
第\ref{fig:TwoWayFixProb}には再帰的マクロのようなものを作る方法を2通り示した．
\verb|nthd|で示される1番目の戦略は，単にマクロを再帰関数の呼び出しへ展開させることだ．
例えばマクロが引数にクォートを付ける手間を省くためだけに使われているのなら，
この手法で十分だろう．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro nthd (n lst)
  `(nth-fn ,n ,lst))

(defun nth-fn (n lst)
  (if (= n 0)
    (car lst)
    (nth-fn (- n 1) (cdr lst))))

(defmacro nthe (n lst)
  `(labels ((nth-fn (n lst)
              (if (= n 0)
                  (car lst)
                  (nth-fn (- n 1) (cdr lst)))))
     (nth-fn ,n ,lst)))
\end{FramedVerb}\end{center}
\caption{問題の2通りの修正方法．}
\label{fig:TwoWayFixProb}
\end{figure}

マクロが必要な理由が，その展開形を丸ごと呼出側のレキシカルな環境に挿入したいということなら，
\verb|nthe|に例示した方法の方ががよいだろう．
組込みの特殊式\verb|labels|（第2.7節を参照）がローカルな関数定義を作っている．
\verb|nthc|の展開形はいずれもグローバル関数\verb|nth-fn|を呼んでいたが，
\verb|nthe|の展開形はそれぞれの内部に同様な関数を持っている．

再帰関数を直接マクロに変換できなくても，展開形が再帰的に生成されるマクロを書くことはできる．
マクロを展開する関数はLispの通常の関数であって，もちろん再帰的になり得る．
例えば組込みの\verb|or|を独自に定義するときには，
再帰的な展開関数を使うことになるだろう．

第\ref{fig:RecExpansionFunc}図には，
\verb|or|のための再帰的な展開関数を定義する方法を2通り示した．
マクロ\verb|ora|は展開形を作るために再帰関数\verb|or-expand|を呼び出す．
これは適切に動作する．また等価な\verb|orb|も同様だ．
\verb|orb|は再帰的だが，
マクロの引数そのものについて再帰的であり（これは展開時にアクセスできる），
その値について再帰的なのではない（こちらはアクセスできない）．
展開形が\verb|orb|そのものへの参照を含むようにも見えるが，
ある1段階のマクロ展開で生成された\verb|orb|の呼び出しは
次の段階で\verb|let|に置き換えられ，
展開の最終形では入れ子になった\verb|let|のスタックしか残らない．
\verb|(orb x y)|は次のコードと等価なコードに展開される．
\begin{verbatim}
(let ((g2 x))
  (if g2
      g2
      (let ((g3 y))
        (if g3 g3 nil))))
\end{verbatim}
実際\verb|ora|と\verb|orb|は等価であり，どちらを使うかは個人的な好みの問題に過ぎない．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro ora (&rest args)
  (or-expand args))

(defun or-expand (args)
  (if (null args)
      nil
      (let ((sym (gensym)))
        `(let ((,sym ,(car args)))
           (if ,sym
               ,sym
               ,(or-expand (cdr args)))))))

(defmacro orb (&rest args)
  (if (null args)
      nil
      (let ((sym (gensym)))
        `(let ((,sym ,(car args)))
           (if ,sym
               ,sym
               (orb ,@(cdr args)))))))
\end{FramedVerb}\end{center}
\caption{再帰的展開関数．}
\label{fig:RecExpansionFunc}
\end{figure}
%}} }
%}}}
\section{古典的なマクロ} %{{{
この章では，一番よく使われる種類のマクロを定義する方法を示す．
それらは\wadash かなり重複が生じるが\wadash 3種類に分けられる．
1種類目はコンテキストを作るマクロだ．
オペレータが引数を新しいコンテキスト内で評価するものなら，
おそらくマクロとして定義されなければならないだろう．
始めの2節は基本的な2種類のコンテキストについて説明し，
それぞれに対してマクロを定義する方法を示す．

続く3節は条件付き評価と反復評価のためのマクロについて説明する．
オペレータが引数を1回より少なく，または複数回評価するものなら，
やはりマクロとして定義されなければならない．
条件付き評価のためのマクロと反復評価のためのマクロとの間には明確な区別はない．
この章で示した例の幾つかは両方を兼ねる（束縛と同様に）．
最後の節は条件付き評価のためのマクロと反復評価のためのマクロとの間のもう1つの類似性について説明する．
場合によっては，どちらも関数によって実現できるのだ．
\subsection{コンテキストの生成}   %{{{
コンテキストには2つの意味がある．
1種類目のコンテキストとはレキシカルな環境だ．
特殊式\verb|let|は新しいレキシカル環境を作る．
\verb|let|の本体内の式は新しい変数を含んでいるかも知れないような環境内で評価される．
\verb|x|がトップレベル内で\verb|a|に設定されたとする．
しかし次の式は\verb|(b)|を返す．
\begin{verbatim}
(let ((x 'b)) (list x))
\end{verbatim}
これは値が\verb|b|である新しい変数\verb|x|を含む環境内で\verb|list|が呼ばれたからだ．

式を実行本体として取るオペレータは普通はマクロとして定義されなければならない．
\verb|prog1|や\verb|progn|などの場合を除けば，
そのようなオペレータの目的は普通は本体部を何か新しいコンテキスト内で評価させることだろう．
コンテキストを生成するコードで本体部の外を覆うためには，
コンテキストが新しいレキシカル変数を含まないときであっても，マクロが必要になる．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro our-let (binds &body body)
  `((lambda ,(mapcar #'(lambda (x)
                         (if (consp x) (car x) x))
                     binds)
      ,@body)
    ,@(mapcar #'(lambda (x)
                   (if (consp x) (cadr x) nil))
               binds)))
\end{FramedVerb}\end{center}
\caption{letのマクロによる実装．}
\label{fig:MacroLet}
\end{figure}

第\ref{fig:MacroLet}図には\verb|let|がどのように\verb|lambda|上のマクロとして定義できるかを示した．
\verb|our-let|は関数アプリケーションに展開される\wadash
\begin{verbatim}
(our-let ((x 1) (y 2))
  (+ x y))
\end{verbatim}
これは次のようになる．
\begin{verbatim}
((lambda (x y) (+ x y)) 1 2)
\end{verbatim}

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro when-bind ((var expr) &body body)
  `(let ((,var ,expr))
     (when ,var
       ,@body)))

(defmacro when-bind* (binds &body body)
  (if (null binds)
      `(progn ,@body)
      `(let (,(car binds))
         (if ,(caar binds)
             (when-bind* ,(cdr binds) ,@body)))))

(defmacro with-gensyms (syms &body body)
  `(let ,(mapcar #'(lambda (s)
                     `(,s (gensym)))
                 syms)
     ,@body))
\end{FramedVerb}\end{center}
\caption{変数を束縛するマクロの例．}
\label{fig:MacroBindsVar}
\end{figure}

第\ref{fig:MacroBindsVar}図にはレキシカル環境を作り出す新マクロを3個載せた．
第7.5節では\verb|when-bind|を引数リストの構造化代入の例として扱ったので，
このマクロはすでにchingページに説明されている．
更に一般的な\verb|when-bind*|は\verb|(|\emph{symbol expression}\verb|)|の形のペアから成るリストを取る\wadash
\verb|let|の引数と同じ形式だ．
どれかの式が\verb|nil|を返したら，式\verb|when-bind*|全体の値として\verb|nil|が返される．
そうでなければそれぞれのシンボルが\verb|let*|と同様に束縛された状態で本体部が評価される：
\begin{verbatim}
> (when-bind* ((x (find-if #'consp '(a (1 2) b)))
                       (y (find-if #'oddp x)))
        (+ y 10))
11
\end{verbatim}

最後に，マクロ\verb|with-gensyms|はそれ自身がマクロを書くために使われる．
多くのマクロ定義はgensymの生成から始まるが，それは時としてかなりの数に昇る．
マクロ\verb|with-redraw| (p. 115)では5個だった．
\begin{verbatim}
(defmacro with-redraw ((var objs) &body body)
  (let ((gob (gensym))
           (x0 (gensym)) (y0 (gensym))
           (x1 (gensym)) (y1 (gensym)))
        ...))
\end{verbatim}
このようなマクロ定義は，\verb|with-gensyms|によって簡潔になる．
これはリスト内の変数を全てgensymに束縛するものだ．
このマクロを使えば，ただ次のように書けばよい．
\begin{verbatim}
(defmacro with-redraw ((var objs) &body body)
  (with-gensyms (gob x0 y0 x1 y1)
        ...))
\end{verbatim}
この新マクロは以降の章を通じて使われる．

幾つかの変数を束縛し，その後何かの条件に基づいて式の組の中の1つを評価したいとき，
\verb|let|内でただ条件判断を使っていた．
\begin{verbatim}
(let ((sun-place 'park) (rain-place 'library))
  (if (sunny)
          (visit sun-place)
          (visit rain-place)))
\end{verbatim}
残念なことに，逆の状況には便利な慣用法が存在しない．
つまり実行したいコードは常に同じだが，束縛が何かの条件によって変化するときだ．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro condlet (clauses &body body)
  (let ((bodfn (gensym))
        (vars (mapcar #'(lambda (v) (cons v (gensym)))
                      (remove-duplicates
                        (mapcar #'car
                                (mappend #'cdr clauses))))))
    `(labels ((,bodfn ,(mapcar #'car vars)
                      ,@body))
       (cond ,@(mapcar #'(lambda (cl)
                            (condlet-clause vars cl bodfn))
                        clauses)))))

(defun condlet-clause (vars cl bodfn)
  `(,(car cl) (let ,(mapcar #'cdr vars)
                (let ,(condlet-binds vars cl)
                  (,bodfn ,@(mapcar #'cdr vars))))))


(defun condlet-binds (vars cl)
  (mapcar #'(lambda (bindform)
              (if (consp bindform)
                  (cons (cdr (assoc (car bindform) vars))
                        (cdr bindform))))
          (cdr cl)))
\end{FramedVerb}\end{center}
\caption{\texttt{cond}と\texttt{let}との組み合せ．}
\label{fig:CondLet}
\end{figure}

第\ref{fig:CondLet}図にはそのような状況のためのマクロを示した．
名前から分かるように，\verb|condlet|は\verb|cond|と\verb|let|との合の子のような働きをする．
これは束縛指定の節と，その次の実行本体部を引数に取る．
それぞれの束縛節はテスト式によって守られている．
コード本体部はテスト式が真を返した最初の節に指定された束縛の下で評価される．
一部の節にのみ含まれる変数は，真となった節が束縛を指定していなければ\verb|nil|に束縛される．
\begin{verbatim}
> (condlet (((= 1 2) (x (princ 'a)) (y (princ 'b)))
            ((= 1 1) (y (princ 'c)) (x (princ 'd)))
            (t          (x (princ 'e)) (z (princ 'f))))
           (list x y z))
CD
(D C NIL)
\end{verbatim}

\verb|condlet|の定義は\verb|our-let|の定義の一般化として捉えられる．
後者は本体部を関数に変え，その関数が初期値を決める式の評価結果に適用されるようにする．
\verb|condlet|は\verb|labels|を使ってローカルな関数を定義しているコードに展開される．
その中では初期値を決める式のどの組が評価されて関数に渡されるかをcond節が決めるようになっている．

展開コードは束縛指定節から変数名を抽出するために
\verb|mapcan|でなく\verb|mappend|を使っていることに注意しよう．
これは\verb|mapcan|が破壊的であって，第10.3章で警告したように，
引数のリスト構造に変更を加えることは危険だからだ．
%}}}
\subsection{\texttt{with-}系マクロ}   %{{{
レキシカル環境の他に，もう1種のコンテキストがある．
そのコンテキストとは，広い意味で世界の状態のことを指す．
これはスペシャル変数の値，データ構造体の内容，Lisp外部の事物の状態を含む．
この種のコンテキストを作り出すオペレータも，
コード本体がクロージャとしてまとめられていない限り，やはりマクロとして定義されなければならない．

コンテキスト生成マクロの名前はしばしば\verb|with-|で始まる．
この種のマクロの中で一番よく使われるのは多分\verb|with-open-file|だろう．
その本体は新しく開かれたファイルが指定の変数に束縛された状態で評価される．
\begin{verbatim}
(with-open-file (s "dump" :direction :output)
  (princ 99 s))
\end{verbatim}
この式の評価後にはファイル「\verb|dump|」は自動的に閉じられ，中身は2文字「99」となっているだろう．

このオペレータは\verb|s|を束縛するので，明らかにマクロとして定義されなければならない．
しかし式を新しいコンテキスト内で評価させるようなオペレータは，
とにかくマクロとして定義されなければならないのだ．
マクロ\verb|ignore-errors|は\textsf{CLtL2}で新たに追加されたものだが，
これはその引数が\verb|progn|内にあるかのように評価されるようにする．
いずれかの時点でエラーが発生すると，式\verb|ignore-errors|全体が\verb|nil|を返す．
(これは，例えばユーザの入力したテキストを読み込む際などに便利だ．)
\verb|ignore-errors|は変数を作る訳ではないが，マクロとして定義されなければならない．
その引数が新しいコンテキスト内で評価されるからだ．

一般的に言って，コンテキストを生成するマクロはコードのブロックに展開される．
本体の前，後，または両方に式が付加されるかもしれない．
そのコードが本体の前に来たときは，その目的はシステムを定常状態に保つことかも知れない\wadash
つまり何らかの後始末だ．
例えば\verb|with-open-file|は，自分が開いたファイルを閉じなければならない．
そのような状況下では，\verb|unwind-protect|に展開されるコンテキスト生成マクロを作るのが定石だ．

\verb|unwind-protect|の目的は，プログラムの実行が割り込みされたときであっても，
ある式が必ず評価されるようにすることだ．
それは1個以上の引数を取り，それらが順に評価される．
何事もなければ\verb|prog1|と同様に第1引数の値を返す．
それとの違いは，第1引数の評価がエラーや\verb|throw|によって中断されたときでさえも，
残りの引数が評価される点だ．
\begin{verbatim}
> (setq x 'a)
A> (unwind-protect
        (progn (princ "What error?")
                 (error "This error."))
        (setq x 'b))
What error?
>>Error: This error.
\end{verbatim}
式\verb|unwind-protect|全体としてはエラーを返す．
しかしトップレベルに戻った後には，第2引数も評価されていたことに気が付く：
\begin{verbatim}
>x
B
\end{verbatim}
これは\verb|with-open-file|が\verb|unwind-protect|に展開されたことで，
本体の評価中にエラーが起きても普通なら開かれたファイルが閉じられるからだ．

コンテキスト生成マクロは，大抵は特定の用途のために作られる．
例として，複数の遠隔データベースを扱うプログラムを書いているとしよう．
プログラムはグローバル変数\verb|*db*|で指定されるデータベース1個ずつに命令する．
データベースの使用前には，他人が同時に使うことがないようにそれをロックしなければならない．
また作業が済んだらロックを解除しなければならない．
データベース\verb|db|のクエリ\verb|q|の値が欲しいときは，次のようにするだろう．
\begin{verbatim}
(let ((temp *db*))
  (setq *db* db)
  (lock *db*)
  (prog1 (eval-query q)
    (release *db*)
    (setq *db* temp)))
\end{verbatim}
マクロを使えば煩わしい作業を全て隠蔽できる．
第\ref{fig:TypicalWithMacro}図では，
高い抽象化レベルでデータベースを扱えるようにしてくれるマクロを定義した．
\verb|with-db|を使えば，ただこうするだけでよい．
\begin{verbatim}
(with-db db
  (eval-query q))
\end{verbatim}
\verb|with-db|は単なる\verb|prog1|でなく\verb|unwind-protect|に展開されるので，
安全に呼び出せる．

\begin{figure}\begin{center}
\fbox{~\,\begin{minipage}{\FrameWidth}\narrowbaselines
\vspace{3pt}\hspace{10zw}純粋なマクロ：
\begin{center}\begin{minipage}{240pt}\texttt{%
(defmacro with-db (db \&body body)\\
~~(let ((temp (gensym)))\\
~~~~`(let ((,temp *db*))\\
~~~~~~~(unwind-protect\\
~~~~~~~~~(progn\\
~~~~~~~~~~~(setq *db* ,db)\\
~~~~~~~~~~~(lock *db*)\\
~~~~~~~~~~~,@body)\\
~~~~~~~~~(progn\\
~~~~~~~~~~~(release *db*)\\
~~~~~~~~~~~(setq *db* ,temp))))))%
}\end{minipage}\end{center}
\hspace{10zw}マクロと関数との組合せ：
\begin{center}\begin{minipage}{240pt}\texttt{%
(defmacro with-db (db \&body body)\\
~~(let ((gbod (gensym)))\\
~~~~`(let ((,gbod \#'(lambda () ,@body)))\\
~~~~~~~(declare (dynamic-extent ,gbod))\\
~~~~~~~(with-db-fn *db* ,db ,gbod))))\\
\\
(defun with-db-fn (old-db new-db body)\\
~~(unwind-protect\\
~~~~(progn\\
~~~~~~(setq *db* new-db)\\
~~~~~~(lock *db*)\\
~~~~~~(funcall body))\\
~~~~(progn\\
~~~~~~(release *db*)\\
~~~~~~(setq *db* old-db))))
}\end{minipage}\end{center}
\vspace{1.3em}\end{minipage}~\,}\end{center}
\caption{典型的な\texttt{with-}系マクロ．}
\label{fig:TypicalWithMacro}
\end{figure}


第\ref{fig:TypicalWithMacro}図内の2つの\verb|with-db|の定義は，
この種のマクロの2通りの書き方の可能性を示している．
1番目は純粋なマクロで，2番目は関数とマクロとの組み合わせだ．
実現したい\verb|with-|系マクロが複雑になるに連れ，2番目の手法の方が実用的になる．

\textsf{CLtL2}準拠のCommon Lisp処理系では，
宣言\verb|dynamic-extent|によって本体部を括るクロージャが効率的に割り当てられるようにできる
（\textsf{CLtL1}準拠の処理系では無視される）．
このクロージャは\verb|with-db-fn|を呼んでいる間だけ必要なので，その通りのことを宣言すれば，
必要なメモリ空間をコンパイラにスタック上に割り当てさせることができる．
この空間は後でガーベジ・コレクタに回収されるのではなく，式から出るときに自動的に回収される．
%}}}
\subsection{条件付き評価}   %{{{
マクロ呼び出し内の引数を，ある条件が成立するときだけ評価したいことがある．
これは，引数を必ず評価することになっている関数にはできないことだ．
\verb|if|，\verb|and|や\verb|cond|のような組込みオペレータは引数の幾つかを保護していて，
他の引数がある値を返さない限り評価しない．
例えば次の式では，
\begin{verbatim}
(if t 'phew
      (/ x 0))
\end{verbatim}
第3引数は評価されると「ゼロ除算」エラーを引き起こす．
しかし1，2番目の引数だけが評価されることになるので，\verb|if|全体としては常に安全に\verb|phew|を返す．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro if3 (test t-case nil-case ?-case)
  `(case ,test
     ((nil) ,nil-case)
     (?       ,?-case)
     (t       ,t-case)))

(defmacro nif (expr pos zero neg)
  (let ((g (gensym)))
    `(let ((,g ,expr))
       (cond ((plusp ,g) ,pos)
             ((zerop ,g) ,zero)
             (t ,neg)))))
\end{FramedVerb}\end{center}
\caption{条件付き評価のためのマクロ．}
\label{fig:MacrosForCondEval}
\end{figure}
\begin{verbatim}
\end{verbatim}

このようなオペレータを新しく書くには，既存のこのようなオペレータに展開されるようなマクロを書けばよい．
第\ref{fig:MacrosForCondEval}には，\verb|if|の考え得る多くの変種のうち2つを示した．
\verb|if3|の定義は，三値論理のための条件判断を定義する方法を示している．
\verb|nil|を偽，そのほか全てを真とするのではなく，
このマクロは真理の3種類の度合を考慮する：
真，偽，そして \verb|?| で表される可能だ．
これは5歳の子供を描写する際に次のように使えるかも知れない．
\begin{verbatim}
(while (not sick)
  (if3 (cake-permitted)
         (eat-cake)
         (throw 'tantrum nil)
         (plead-insistently)))
\end{verbatim}

この新しい条件判断オペレータは\verb|case|に展開される．
(キー\verb|nil|はリストに括らなければならない．
\verb|nil|単独では意味があいまいになるからだ．)
最後の3つの引数は，第1引数の値に従ってどれか1つだけが評価される．

\verb|nif|という名前は「numeric if（数値的if）」から来ている．
別の実装方法はbnmページに示した．
これは数値の式を第1引数に取り，その符号に従って残り3つの引数のどれかを評価する．
\begin{verbatim}
> (mapcar #'(lambda (x)
                   (nif x 'p 'z 'n))
              '(0 1 -1))
(ZPN)
\end{verbatim}

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro in (obj &rest choices)
  (let ((insym (gensym)))
    `(let ((,insym ,obj))
       (or ,@(mapcar #'(lambda (c) `(eql ,insym ,c))
                      choices)))))

(defmacro inq (obj &rest args)
  `(in ,obj ,@(mapcar #'(lambda (a)
                           `',a)
                       args)))

(defmacro in-if (fn &rest choices)
  (let ((fnsym (gensym)))
    `(let ((,fnsym ,fn))
       (or ,@(mapcar #'(lambda (c)
                          `(funcall ,fnsym ,c))
                      choices)))))

(defmacro >case (expr &rest clauses)
  (let ((g (gensym)))
    `(let ((,g ,expr))
       (cond ,@(mapcar #'(lambda (cl) (>casex g cl))
                        clauses)))))

(defun >casex (g cl)
  (let ((key (car cl)) (rest (cdr cl)))
    (cond ((consp key) `((in ,g ,@key) ,@rest))
          ((inq key t otherwise) `(t ,@rest))
          (t (error "bad >case clause")))))
\end{FramedVerb}\end{center}
\caption{条件付き評価のためのマクロ．}
\label{fig:MacrosForCondEval2}
\end{figure}
\begin{verbatim}
\end{verbatim}

第\ref{fig:MacrosForCondEval2}図には，条件付き評価の利点を生かしたマクロを更に幾つか示した．
マクロ\verb|in|は集合への所属関係を効率的に調べるものだ．
あるオブジェクトが幾つかのオブジェクトの中のどれかと同じものか調べたいとき，
その問は選言（訳注：いわゆるor）として表現できる．
\begin{verbatim}
(let ((x (foo)))
  (or (eql x (bar)) (eql x (baz))))
\end{verbatim}
または同じ事を集合への所属関係としても表現できる．
\begin{verbatim}
(member (foo) (list (bar) (baz)))
\end{verbatim}
後者の方が抽象的だが，非効率的だ．
\verb|member|を使った式には2つの理由で不必要なコストがかかる．
これはオブジェクトの集合を\verb|member|が調べるためにリストに括らなければならないので，
コンシングを起こす．
そしてオブジェクトの集合をリストに括るためにはそれらを全て評価しなければならないが，
中には全く必要でない値もある．
\verb|(foo)|の値が\verb|(bar)|の値に等しければ，\verb|(baz)|を評価する必要はない．
概念としてはどれ程優れていても，このように\verb|member|を使うのはよい方法ではない．
同様な抽象化はマクロによればより効率的に実現できる．
\verb|in|は\verb|member|の抽象性と\verb|or|の効率性を併せ持ったものだ．
\verb|in|を使った等価な式は\verb|member|の式と同じ形をしている．
\begin{verbatim}
(in (foo) (bar) (baz))
\end{verbatim}
しかしこれは次のように展開される．
\begin{verbatim}
(let ((#:g25 (foo)))
  (or (eql #:g25 (bar))
         (eql #:g25 (baz))))
\end{verbatim}

よくあることだが，慣用法の明確なものと効率的なものとの間の選択に直面したときは，
前者を後者に変換するマクロを書くことでディレンマの角を抜けることができる
（訳注：「どちらかの選択」に実は第3の道があること）．

\verb|inq|は``in queue''と発音するが，これはクォートを使う\verb|in|の変種で，
これを使うのは\verb|set|の代わりに\verb|setq|を使うようなものだ．
次の式は，
\begin{verbatim}
(inq operator + - *)
\end{verbatim}
次のように展開される．
\begin{verbatim}
(in operator '+ '- '*)
\end{verbatim}
\verb|member|のデフォルト動作と同様に，\verb|in|と\verb|inq|は同一性の判断に\verb|eql|を使う．
判断に他のオペレータを使いたいなら\wadash 1個の引数を取る関数なら何でもよいが\wadash
更に一般的な\verb|in-if|を使うとよい．
\verb|in-if|と\verb|some|との関係はちょうど\verb|in|と\verb|member|との関係と同じだ．
次の式は，
\begin{verbatim}
(member x (list a b) :test #'equal)
\end{verbatim}
次のように書き換えられる．
\begin{verbatim}
(in-if #'(lambda (y) (equal x y)) a b)
\end{verbatim}
同様に次の式は，
\begin{verbatim}
(some #'oddp (list a b))
\end{verbatim}
次のようになる．
\begin{verbatim}
(in-if #'oddp a b)
\end{verbatim}

\verb|cond|と\verb|in|を組み合わせることで，\verb|case|の便利な変種が定義できる．
Common Lispのマクロ\verb|case|のキーが定数であることを前提にしている．
しかし\verb|case|の動作が欲しいが，キーを評価して欲しいときもある．
\verb|>case|はそのような場合のために作られた．
これは\verb|case|と似ているが，それぞれの節を保護するキーが比較前に評価されるようになっている．
(名前の「 \verb|>| 」は矢印が評価を表すつもりで付けられた．)
\verb|>case|は\verb|in|を使っているので，必要以上のキーは評価しない．

キーはLispの式であってもよいので，
\verb|(x y)|が関数やマクロの呼び出しなのか2つのキーから成るリストなのか判断が付かない．
曖昧さをなくすため，（\verb|t|以外の）キーは，
1つしかない場合でも必ずリストに括られていなければならない．
\verb|case|の場合，曖昧であるために\verb|nil|は節の\verb|car|部になってはいけなかった．
\verb|>case|では，\verb|nil|は節の\verb|car|部として曖昧ではない．
しかしそうすると節の残りが決して評価されないことになる．

明確さのため，
それぞれの\verb|>case|節の展開形を生成するコードは独立した関数\verb|>casex|として定義された．
\verb|>casex|自身も\verb|inq|を使っていることに注意しよう．
%}}}
\subsection{反復}   %{{{
関数にまつわる問題が，引数が必ず評価されることではなく，引数が1回しか評価されないことであるときもある．
関数の引数はどれもきっかり1回だけ評価されるので，
本体となる式を取ってそれを反復評価するオペレータを定義したければ，
それをマクロとして定義するしかない．

一番単純な例は，引数を順番に永遠に評価し続けるマクロだろう．
\begin{verbatim}
(defmacro forever (&body body)
  `(do ()
     (nil)
     ,@body))
\end{verbatim}
これはちょうど組込みマクロ\verb|loop|にキーワードを与えなかったときの動作だ．
永遠の繰り返しには大した将来性はないように思える（むしろ将来に渡って続き過ぎる）．
しかし\verb|block|や\verb|return-from|と組み合わせれば，
この種のマクロが，中断は緊急時のみであるようなループを表現するための一番自然な方法になる．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro while (test &body body)
  `(do ()
     ((not ,test))
     ,@body))

(defmacro till (test &body body)
  `(do ()
     (,test)
     ,@body))

(defmacro for ((var start stop) &body body)
  (let ((gstop (gensym)))
    `(do ((,var ,start (1+ ,var))
          (,gstop ,stop))
       ((> ,var ,gstop))
       ,@body)))
\end{FramedVerb}\end{center}
\caption{単純な反復用マクロ．}
\label{fig:SimpleIterMacro}
\end{figure}
\begin{verbatim}
\end{verbatim}

反復のためのマクロの単純な例を幾つか第\ref{fig:SimpleIterMacro}に示した．
\verb|while|はすでに見たものだ(p. vom)．
この本体部はテスト式が真を返す間中評価され続ける．
\verb|till|はそれと対をなすもので，テスト式が偽を返す間評価を繰り返す．
最後の\verb|for|もすでに見た(p. qwe)もので，ある範囲の数に対して反復を行う．

これらのマクロを\verb|do|に展開するようにすることで，
その本体部の中で\verb|go|や\verb|return|が使えるようになる．
\verb|do|の持つこの性質は\verb|block|と\verb|tagbody|から引き継いだものだから，
\verb|while|，\verb|till|と\verb|for|は\verb|do|からやはり引き継ぐことになる．
zxcページで説明したように，
\verb|do|を囲む暗黙のブロックのタグ\verb|nil|は第\ref{fig:SimpleIterMacro}図のマクロに捕捉される．
この点はバグというより仕様だが，最低でも明記しておくべきだ．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro do-tuples/o (parms source &body body)
  (if parms
      (let ((src (gensym)))
        `(prog ((,src ,source))
               (mapc #'(lambda ,parms ,@body)
                     ,@(map0-n #'(lambda (n)
                                    `(nthcdr ,n ,src))
                                (1- (length parms))))))))

(defmacro do-tuples/c (parms source &body body)
  (if parms
      (with-gensyms (src rest bodfn)
                    (let ((len (length parms)))
                      `(let ((,src ,source))
                         (when (nthcdr ,(1- len) ,src)
                           (labels ((,bodfn ,parms ,@body))
                             (do ((,rest ,src (cdr ,rest)))
                               ((not (nthcdr ,(1- len) ,rest))
                                ,@(mapcar #'(lambda (args)
                                               `(,bodfn ,@args))
                                           (dt-args len rest src))
                                nil)
                               (,bodfn ,@(map1-n #'(lambda (n)
                                                      `(nth ,(1- n)
                                                            ,rest))
                                                  len))))))))))

(defun dt-args (len rest src)
  (map0-n #'(lambda (m)
              (map1-n #'(lambda (n)
                          (let ((x (+ m n)))
                            (if (>= x len)
                                `(nth ,(- x len) ,src)
                                `(nth ,(1- x) ,rest))))
                      len))
          (- len 2)))
\end{FramedVerb}\end{center}
\caption{部分リストに渡る再帰のためのマクロ．}
\label{fig:MacroForIterBySubSeq}
\end{figure}
\begin{verbatim}
\end{verbatim}

さらに強力な反復構造を定義する必要があるときにはマクロは必要不可欠だ．
第\ref{fig:MacroForIterBySubSeq}図には\verb|dolist|の一般化を2つ示した．
両方とも変数の組をリストの隣り合った部分リストに束縛した状態で本体部を評価する．
例えば\verb|do-tuples/o|は引数を2つ取り，リストの要素に渡って反復を行う．
\begin{verbatim}
> (do-tuples/o (x y) '(a b c d)
               (princ (list x y)))
(a b)(b c)(c d)
nil
\end{verbatim}
同じ引数に対しては\verb|do-tuples/c|も同じ動作をするが，こちらはリスト末尾で先頭につながる．
\begin{verbatim}
> (do-tuples/c (x y) '(a b c d)
               (princ (list x y)))
(a b)(b c)(c d)(d a)
nil
\end{verbatim}
どちらのマクロも本体内で陽に\verb|return|が使われない限り\verb|nil|を返す．

この種の反復は経路の概念を何らかの形で扱うプログラムでしばしば必要になる．
名前の末尾の\verb|/o|と\verb|/c|は，
それぞれが開いた(open)経路と閉じた(closed)経路を探索することを表すつもりで付けられた．
例えば\verb|points|が点のリストで，\verb|(drawline x y)|が\verb|x|と\verb|y|との間に線分を描くものとしよう．
最初の点から最後の点まで折れ線を描くにはこうすればよい．
\begin{verbatim}
(do-tuples/o (x y) points (drawline x y))
\end{verbatim}
しかし\verb|points|が多角形の頂点のリストだったら，その外周を描くにはこうすればよい．
\begin{verbatim}
(do-tuples/c (x y) points (drawline x y))
\end{verbatim}
第1引数として渡された引数のリストは任意の長さでよく，反復はその長さと同数の変数の組に渡って行われる．
引数が1個だけのときは，共に\verb|dolist|に縮退する．
\begin{verbatim}
> (do-tuples/o (x) '(a b c) (princ x))
abc
NIL
> (do-tuples/c (x) '(a b c) (princ x))
ABC
NIL
\end{verbatim}

\verb|do-tuples/c|の定義は\verb|do-tuples/o|より複雑になっている．
これはリスト末尾に届いたときに先頭につながるようにしているせいだ．
$n$個の引数があれば，\verb|do-tuples/c|は値を返す前に$n-1$回余計に反復を行わなければならない．
\begin{verbatim}
> (do-tuples/c (x y z) '(abcd)
               (princ (list x y z)))
(A B C)(B C D)(C D A)(D A B)
NIL

> (do-tuples/c (wxyz)'(abcd)
               (princ (list w x y z)))
(A B C D)(B C D A)(C D A B)(D A B C)
NIL
\end{verbatim}
\verb|do-tuples/c|の呼び出しの1つ目の展開形は第\ref{fig:Expansiondo-tuples/c}に示した．
生成し辛いのは，リスト先頭へつながることを表す呼び出しの連続だ．
これらの呼び出しは（この場合はそれらのうち2つ）\verb|dt-args|によって生成される．

\begin{figure}\begin{center}
\fbox{~\,\begin{minipage}{\FrameWidth}\narrowbaselines
\vspace{3pt}
\begin{center}\begin{minipage}{240pt}\texttt{%
(do-tuples/c (x y z) '(a b c d)\\
~~~~~~~~~~~~~(princ (list x y z)))
}\end{minipage}\end{center}
\hspace{12zw}は次のように展開される：
\begin{center}\begin{minipage}{240pt}\texttt{%
(let ((\#:g2 '(a b c d)))\\
~~(when (nthcdr 2 \#:g2)\\
~~~~(labels ((\#:g4 (x y z)\\
~~~~~~~~~~~~~~~(princ (list x y z))))\\
~~~~~~(do ((\#:g3 \#:g2 (cdr \#:g3)))\\
~~~~~~~~((not (nthcdr 2 \#:g3))\\
~~~~~~~~~(\#:g4 (nth 0 \#:g3)\\
~~~~~~~~~~~~~~~(nth 1 \#:g3)\\
~~~~~~~~~~~~~~~(nth 0 \#:g2))\\
~~~~~~~~~(\#:g4 (nth 1 \#:g3)\\
~~~~~~~~~~~~~~~(nth 0 \#:g2)\\
~~~~~~~~~~~~~~~(nth 1 \#:g2))\\
~~~~~~~~~nil)\\
~~~~~~~~(\#:g4 (nth 0 \#:g3)\\
~~~~~~~~~~~~~~(nth 1 \#:g3)\\
~~~~~~~~~~~~~~(nth 2 \#:g3))))))
}\end{minipage}\end{center}
\vspace{1.3em}\end{minipage}~\,}\end{center}
\caption{\texttt{do-tuples/c}の呼び出しの展開形．}
\label{fig:Expansiondo-tuples/c}
\end{figure}

%}}}
\subsection{複数の値に渡る反復}   %{{{

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro mvdo* (parm-cl test-cl &body body)
  (mvdo-gen parm-cl parm-cl test-cl body))

(defun mvdo-gen (binds rebinds test body)
  (if (null binds)
      (let ((label (gensym)))
        `(prog nil
               ,label
               (if ,(car test)
                   (return (progn ,@(cdr test))))
               ,@body
               ,@(mvdo-rebind-gen rebinds)
               (go ,label)))
      (let ((rec (mvdo-gen (cdr binds) rebinds test body)))
        (let ((var/s (caar binds)) (expr (cadar binds)))
          (if (atom var/s)
              `(let ((,var/s ,expr)) ,rec)
              `(multiple-value-bind ,var/s ,expr ,rec))))))

(defun mvdo-rebind-gen (rebinds)
  (cond ((null rebinds) nil)
        ((< (length (car rebinds)) 3)
         (mvdo-rebind-gen (cdr rebinds)))
        (t(cons (list (if (atom (caar rebinds))
                          'setq
                          'multiple-value-setq)
                      (caar rebinds)
                      (third (car rebinds)))
                (mvdo-rebind-gen (cdr rebinds))))))
\end{FramedVerb}\end{center}
\caption{多値に対応した\texttt{do*}．}
\label{fig:MultiValBindDostar}
\end{figure}

組込みマクロ\verb|do|の歴史は多値よりも古い．
幸い\verb|do|は新しい状況に適応するように進化することができる．
Lispの進化はプログラマの手の中にあるからだ．
第\ref{fig:MultiValBindDostar}には多値に対応した\verb|do*|の変種を示した．
\verb|mvdo*|を使えば，始めの節は複数個の変数を束縛できる．
\begin{verbatim}
> (mvdo* ((x 1 (1+ x))
          ((y z) (values 0 0) (values z x)))
         ((> x 5) (list x y z))
         (princ (list x y z)))
(1 0 0)(2 0 2)(3 2 3)(4 3 4)(5 4 5)
(656)
\end{verbatim}
この種の反復は，例えばインタラクティブなグラフィックス・プログラムで便利になる．
それにはしばしば座標や領域などの複数の数量を扱う必要があるからだ．

単純なインタラクティブ・ゲームを書きたいとしよう．
目的は追ってくる2個の敵に挟まれるのを避けることだ．
敵が同時にぶつかってきたら，ゲームは負け．
それぞれ単独でぶつかると，勝ちになる．
第\ref{fig:GameSquash}図には，このゲームのメイン・ループを\verb|mvdo*|を使って書く方法を示した．

\begin{figure}\begin{center}
\fbox{~\,\begin{minipage}{\FrameWidth}\narrowbaselines
\vspace{3pt}
\begin{center}\begin{minipage}{320pt}\texttt{%
(mvdo* (((px py) (pos player)~~~(move player mx my))\\
~~~~~~~~((x1 y1) (pos obj1)~~~~~(move obj1 (- px x1)\\
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~(- py y1)))\\
~~~~~~~~((x2 y2) (pos obj2)~~~~~(move obj2 (- px x2)\\
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~(- py y2)))\\
~~~~~~~~((mx my) (mouse-vector) (mouse-vector))\\
~~~~~~~~(win~~~~~nil~~~~~~~~~~~~(touch obj1 obj2))\\
~~~~~~~~(lose~~~~nil~~~~~~~~~~~~(and (touch obj1 player)\\
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~(touch obj2 player))))\\
~~~~~~~((or win lose) (if win 'win 'lose))\\
~~~~~~~(clear)\\
~~~~~~~(draw obj1)\\
~~~~~~~(draw obj2)\\
~~~~~~~(draw player))\\
}\end{minipage}\\
\begin{minipage}{.85\textwidth}
\texttt{(pos obj)}は2つの値\texttt{x}と\texttt{y}を返す．
これらは\texttt{obj}の位置を示す．
最初は，3つの物体はランダムな位置に置かれる．

\texttt{(move obj dx dy)}は
オブジェクト\texttt{obj}の型とヴェクタ\texttt{dx}, \texttt{dy}に従って
\texttt{obj}を移動させる．
新しい位置を示す2つの値\texttt{x}と\texttt{y}を返す．

\texttt{(mouse-vector)}はマウスの現在の位置を示す2つの値\texttt{dx}と\texttt{dy}を返す．

\texttt{(touch obj1 obj2)}は，\texttt{obj1}と\texttt{obj2}が接触しているならば真を返す．

\texttt{(clear)}はゲーム領域を消去する．

\texttt{(draw obj)}は\texttt{obj}を現在位置に従って描画する．
\end{minipage}\end{center}
\vspace{1.3em}\end{minipage}~\,}\end{center}
\caption{挟みゲーム．}
\label{fig:GameSquash}
\end{figure}


またローカル変数を並列して束縛する\verb|mvdo|を書くこともできる．
\begin{verbatim}
> (mvdo ((x 1 (1+ x))
         ((y z) (values 0 0) (values z x)))
        ((> x 5) (list x y z))
        (princ (list x y z)))
(1 0 0)(2 0 1)(3 1 2)(4 2 3)(5 3 4)
(645)
\end{verbatim}

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro mvpsetq (&rest args)
  (let* ((pairs (group args 2))
         (syms (mapcar #'(lambda (p)
                           (mapcar #'(lambda (x) (gensym))
                                   (mklist (car p))))
                       pairs)))
    (labels ((rec (ps ss)
                  (if (null ps)
                      `(setq
                         ,@(mapcan #'(lambda (p s)
                                        (shuffle (mklist (car p))
                                                 s))
                                    pairs syms))
                      (let ((body (rec (cdr ps) (cdr ss))))
                        (let ((var/s (caar ps))
                              (expr (cadar ps)))
                          (if (consp var/s)
                              `(multiple-value-bind ,(car ss)
                                 ,expr
                                 ,body)
                              `(let ((,@(car ss) ,expr))
                                 ,body)))))))
      (rec pairs syms))))

(defun shuffle (x y)
  (cond ((null x) y)
        ((null y) x)
        (t (list* (car x) (car y)
                  (shuffle (cdr x) (cdr y))))))
\end{FramedVerb}\end{center}
\caption{多値に対応した\texttt{psetq}．}
\label{fig:MultiValPsetq}
\end{figure}

\verb|do|の定義に\verb|psetq|が必要な点についてはasdページで説明した．
\verb|mvdo|を定義するには，多値に対応した\verb|psetq|が必要だ．
そういうものはCommon Lispにはないので，自分で書かなければならない．
それを第\ref{fig:MultiValPsetq}に示した．
この新しいマクロは次のように動作する．
\begin{verbatim}
> (let ((w 0) (x 1) (y 2) (z 3))
    (mvpsetq (w x) (values 'a 'b) (y z) (values w x))
    (list wxyz))
(AB01)
\end{verbatim}

\verb|mvpsetq|の定義は3つのユーティリティ関数に依存している：
\verb|mklist| (p. sdf)，\verb|group| (p. dfg)に，ここで定義した\verb|shuffle|だ．
それは2つのリストを交互に組み合わせる働きをする．
\begin{verbatim}
> (shuffle '(a b c) '(1 2 3 4))
(A1B2C34)
\end{verbatim}

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro mvdo (binds (test &rest result) &body body)
  (let ((label (gensym))
        (temps (mapcar #'(lambda (b)
                           (if (listp (car b))
                               (mapcar #'(lambda (x)
                                           (gensym))
                                       (car b))
                               (gensym)))
                       binds)))
    `(let ,(mappend #'mklist temps)
       (mvpsetq ,@(mapcan #'(lambda (b var)
                               (list var (cadr b)))
                           binds
                           temps))
       (prog ,(mapcar #'(lambda (b var) (list b var))
                      (mappend #'mklist (mapcar #'car binds))
                      (mappend #'mklist temps))
             ,label
             (if ,test
                 (return (progn ,@result)))
             ,@body
             (mvpsetq ,@(mapcan #'(lambda (b)
                                     (if (third b)
                                         (list (car b)
                                               (third b))))
                                 binds))
             (go ,label)))))
\end{FramedVerb}\end{center}
\caption{多値の束縛に対応した\texttt{do}．}
\label{fig:MultiBindDo}
\end{figure}

\verb|mvpsetq|を使い，\verb|mvdo|は第\ref{fig:MultiBindDo}図のように書ける．
\verb|condlet|と同様，元のマクロ呼び出しに変更を加えるのを避けるため，
このマクロは\verb|mapcar|ではなく\verb|mappend|を使っている．
慣用法\verb|mappend|-\verb|mklist|はツリーを1段階だけ平たくする．
\begin{verbatim}
> (mappend #'mklist '((a b c) d (e (f g) h) ((i)) j))
(ABCDE(FG)H(I)J)
\end{verbatim}

このかなり大きなマクロの理解を助けるため，第\ref{fig:ExpansionOfMvdo}図には展開形の例も示した．

\begin{figure}\begin{center}
\fbox{~\,\begin{minipage}{\FrameWidth}\narrowbaselines
\vspace{3pt}
\begin{center}\begin{minipage}{240pt}\texttt{%
(mvdo ((x 1 (1+ x))\\
~~~~~~~((y z) (values 0 0) (values z x)))\\
~~~~~~((> x 5) (list x y z))\\
~~~~~~(princ (list x y z)))
}\end{minipage}\end{center}
\hspace{12zw}これは次のように展開される：
\begin{center}\begin{minipage}{240pt}\texttt{%
(let (\#:g2 \#:g3 \#:g4)\\
~~(mvpsetq \#:g2 1\\
~~~~~~~~~~~(\#:g3 \#:g4) (values 0 0))\\
~~(prog ((x \#:g2) (y \#:g3) (z \#:g4))\\
~~~~~~~~\#:g1\\
~~~~~~~~(if (> x 5)\\
~~~~~~~~~~~~(return (progn (list x y z))))\\
~~~~~~~~(princ (list x y z))\\
~~~~~~~~(mvpsetq x (1+ x)\\
~~~~~~~~~~~~~~~~~(y z) (values z x))\\
~~~~~~~~(go \#:g1)))
}\end{minipage}\end{center}
\vspace{1.3em}\end{minipage}~\,}\end{center}
\caption{\texttt{mvdo}の呼び出しの展開形．}
\label{fig:ExpansionOfMvdo}
\end{figure}
%}}}
\subsection{マクロの必要性}   %{{{
引数を評価から保護する方法はマクロだけではない．
引数をクロージャで括る方法もある．
条件付き評価と反復評価は，どちらも本質的にマクロが必要な訳ではないので，似たようなものだ．
例えば\verb|if|を関数として書くことができる．
\begin{verbatim}
(defun fnif (test then &optional else)
  (if test
      (funcall then)
      (if else (funcall else))))
\end{verbatim}
then部とelse部に当たる引数はクロージャとして表現することで保護できる．
だから次のようにはせず，
\begin{verbatim}
(if (rich) (go-sailing) (rob-bank))
\end{verbatim}
代わりに次のようにすることになる．
\begin{verbatim}
(fnif (rich)
      #'(lambda () (go-sailing))
      #'(lambda () (rob-bank)))
\end{verbatim}
ただ条件付き評価だけを実現したいなら，マクロが絶対必要というわけではない．
マクロはプログラムを明確にしてくれるだけだ．
しかし引数の式の中身を切り分けたり，引数として渡された変数を束縛するためにはマクロが必要になる．

同じことが反復用のマクロにも当てはまる．
マクロは本体部の式の前に反復構造を定義する唯一の方法だが，
ループ本体が関数そのもので括られている限り，関数で反復を実現できる
\footnote{引数を関数に括る必要のない反復用関数を書くのは不可能ではない．
引数として渡された式で\texttt{eval}を呼ぶ関数が定義できる．
それが\texttt{eval}の使いかたとして良くないことの説明には，werページを参照．}．
例えば組込み関数\verb|mapc|は\verb|dolist|の関数版だ．
\begin{verbatim}
(dolist (b bananas)
  (peel b)
  (eat b))
\end{verbatim}
この式は次と同じ副作用を持つ．
\begin{verbatim}
(mapc #'(lambda (b)
          (peel b)
          (eat b))
      bananas)
\end{verbatim}
(ただし前者は\verb|nil|を，後者はリスト\verb|bananas|を返すが．)
同様に\verb|forever|も，
式本体をクロージャとして渡すようにすれば関数として実装できる．
\begin{verbatim}
(defun forever (fn)
  (do ()
    (nil)
    (funcall fn)))
\end{verbatim}

しかし\verb|forever|でもそうだが，反復構造は普通は反復だけが目的なのではない．
束縛と反復の組み合わせが目的なのが普通だ．
関数を使うと，束縛の方の見込みは限られる．
変数をリストの隣り合う要素にそれぞれ束縛したいときには，対応関数のどれかを使えばよい．
しかし要求されることがずっと込み入ってくると，マクロを書かざるを得ないだろう．
%}}}
%}}}
\section{汎変数} %{{{
第8章では，マクロの利点の1つは引数を変形できる能力だということに触れた．
その種のマクロの1つが\verb|setf|だ．
この章では，\verb|setf|の持つ隠れた意味に視点を向け，その上に構築できるマクロの例を幾つか示す．

\verb|setf|の上に適切なマクロを構築することは，驚く程難しい．
この話題への導入として，最初の節では少々まずい所のある単純な例を示す．
次の節ではそれの何がまずいのかを説明し，改善方法を示す．
その後の2節では\verb|setf|の上に構築されたユーティリティの例を提示し，
最後の節で\verb|setf|の逆に当たる独自のオペレータの定義方法を説明する．
\subsection{概念}   %{{{
組込みマクロ\verb|setf|は\verb|setq|の一般化に当たる．
\verb|setf|の第1引数はただの変数でなく関数やマクロの呼び出しであってもよい．
\begin{verbatim}
> (setq lst '(a b c))
(ABC)
> (setf (car lst) 480)
480
> lst
(480 B C)
\end{verbatim}

一般的には\verb|(setf x y)|は
「\verb|x|が\verb|y|に評価されるようにしておいてくれ」という指示として理解できる．
\verb|setf|はマクロなので，引数の内部を見てそのような指示を実現するには何をすればよいかを判断できる．
（展開後の）1引数がシンボルだったら，\verb|setf|は単に\verb|setq|に展開される．
しかし第1引数が別の変数を求めるための式だったときは，
\verb|setf|は対応する確定した命令(assertion)に展開される．
第2引数は定数なので，前の例は次のように展開されるかもしれない．
\begin{verbatim}
(progn (rplaca lst 480) 480)
\end{verbatim}

このように変数を求める式から決定的な命令へ変換することはインヴァージョン(inversion)と呼ばれる．
\verb|car|，\verb|cdr|，\verb|nth|，\verb|aref|，\verb|get|，\verb|gethash|及び
\verb|defstruct|で定義されるアクセス関数等，Common Lispで頻繁に使われる，
オブジェクトにアクセスするための関数にはインヴァージョンに当たるものが予め定義されている．
(完全な一覧は\textsf{CLtL2}の125ページにある)

\verb|setf|の第1引数として機能する式は汎変数（generalized variable）と呼ばれる．
汎変数は強力な抽象化手段であることが分かっている．
インヴァージョン可能な参照に展開されるマクロ呼び出しは全てそれ自体がインヴァージョン可能という点で，
マクロ呼び出しは汎変数と似ている．

また\verb|setf|の上にマクロも構築すれば，相乗効果によってかなり明確なプログラムができる．
\verb|setf|の上に構築できるマクロの1つは\verb|toggle|だ
\footnote{以下の節で見るように，この定義は正しくない．}．
\begin{verbatim}
(defmacro toggle (obj)               ; 間違い
  `(setf ,obj (not ,obj)))
\end{verbatim}
これは汎変数の値を切替える：
\begin{verbatim}
> (let ((lst '(a b c)))
    (toggle (car lst))
    lst)
(NIL B C)
\end{verbatim}

さて次のアプリケーションを考えよう．
誰かが\wadash 昼のドラマ劇場の脚本家，精力に溢れた社交界の人間，はたまた政党の事務員か\wadash
小さな町の住人の間の人間関係を全て記録したデータベースを運営したいとしよう．
テーブルには住人の友人を記録する欄が必要だ．
\begin{verbatim}
(defvar *friends* (make-hash-table))
\end{verbatim}
このハッシュ表のエントリはそれ自身がハッシュ表で，
ここには友人の候補の名前が\verb|t|または\verb|nil|に結合されている．
\begin{verbatim}
(setf (gethash 'mary *friends*) (make-hash-table))
\end{verbatim}
JohnをMaryの友人として登録するには，次のようにすることになる．
\begin{verbatim}
(setf (gethash 'john (gethash 'mary *friends*)) t)
\end{verbatim}
町は2つのグループに分けられる．
グループというものはいつでも互いに「仲間じゃないやつは敵だ」と言いたがるので，
町の人間はどちらかのグループに属することを余儀なくされる．
だから誰かがグループを移ると，元の友人は敵に，敵は友人に変わる．

組込みオペレータだけによって\verb|x|が\verb|y|の友人かどうかを切替えるには，
次のようにすることになる．
\begin{verbatim}
(setf (gethash x (gethash y *friends*))
      (not (gethash x (gethash y *friends*))))
\end{verbatim}
これはかなり複雑な式だ
（もちろん\verb|setf|なしではこの程度では済まなかっただろうが）．
データベースに次のようなアクセス用マクロを定義していれば，
\begin{verbatim}
(defmacro friend-of (p q)
  `(gethash ,p (gethash ,q *friends*)))
\end{verbatim}
このマクロと\verb|toggle|とで，データベースの変更を扱うためにはかなり準備が整ったことになる．
上の更新操作は簡潔に表現できるだろう．
\begin{verbatim}
(toggle (friend-of x y))
\end{verbatim}

汎変数は美味しい健康食品のようなものだ．
これによってできるプログラムは見事にモジュール化され，それでいて美しくエレガントだ．
データ構造にマクロかインヴァージョン可能な関数を通じてアクセスを提供すれば，
他のモジュールはデータ表現の詳細を知る必要のないまま\verb|setf|でデータ構造を操作できる．
%}}}
\subsection{複数回の評価に関わる問題}   %{{{
前の節では\verb|toggle|の最初の定義はまずい所があると警告した．
\begin{verbatim}
(defmacro toggle (obj)               ; 間違い
  `(setf ,obj (not ,obj)))
\end{verbatim}

これは第10.1節で説明した問題，つまり複数回の評価の元になる．
問題は引数に副作用があるときに起きる．
例えば\verb|lst|がオブジェクトから成るリストで，それを使ってこう書いたとき，
\begin{verbatim}
(toggle (nth (incf i) lst))
\end{verbatim}
$(i+1)$番目の要素の値を切替えているものと思うだろう．
しかし\verb|toggle|の現在の定義ではこのマクロ呼び出しは次のように展開される．
\begin{verbatim}
(setf (nth (incf i) lst)
      (not (nth (incf i) lst)))
\end{verbatim}
これは\verb|i|を2回増加させ，$(i+1)$番目の要素を$(i+2)$番目の要素の逆に設定する．
よって次の例では，
\begin{verbatim}
> (let ((lst '(t nil t))
             (i -1))
        (toggle (nth (incf i) lst))
        lst)
(T NIL T)
\end{verbatim}
\verb|toggle|を呼んでも効果はないようだ．

\verb|toggle|の引数として与えられた式を取り出し，
\verb|setf|の第1引数の場所に挿入するだけでは十分ではない．
式の内部を見て，その動作を知らなければならないのだ．
それが部分式を含むなら，それらが副作用を持つことを考慮し，分割して別個に評価しなければならない．
一般的に言えば，これは複雑な仕事だ．

余計な手間を省くため，
Common Lispは\verb|setf|の上に，ある限られた範囲のマクロを自動的に定義するマクロを提供している．
このマクロは\verb|define-modify-macro|という名前で，3個の引数を取る．
定義したいマクロの名前，（汎変数の後に）取るかもしれない付加的な引数，
そして汎変数の新しい値を返す関数の名前だ
\footnote{これは一般的な意味での関数名だ：
\texttt{1+}または\texttt{(lambda (x) (+ x 1))}のどちらでもよい．}．

\verb|define-modify-macro|を使うと，\verb|define|はこうして定義できる．
\begin{verbatim}
(define-modify-macro toggle () not)
\end{verbatim}

換言すれば，これは「\verb|(toggle place)|の形の式を評価するには，
\verb|place|の指定する位置を見つけ，そしてそこに蓄えられた値が\verb|val|ならば，
それを\verb|(not val)|の値で置き換えること」と指示していることになる．
次は新しいマクロを同じ例に使ったところだ．
\begin{verbatim}
> (let ((lst '(t nil t))
        (i -1))
    (toggle (nth (incf i) lst))
    lst)
(NIL NIL T)
\end{verbatim}

この定義は正しい結果をもたらすが，更に一般化することもできる．
\verb|setf|と\verb|setq|は任意の数の引数を取れるのだから，\verb|toggle|もそうあるべきだ．
第\ref{fig:MacrosOnGnrlVars}に示したように，
この機能は\verb|define-modify-macro|の上に別のマクロを定義することで追加できる．
%}}}
\subsection{新しいユーティリティ}   %{{{
この節では汎変数に対して機能する新しいユーティリティの例を幾つか示す．
引数を\verb|setf|にそのままの形で渡すためには，それらはマクロでなければならない．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro allf (val &rest args)
  (with-gensyms (gval)
    `(let ((,gval ,val))
       (setf ,@(mapcan #'(lambda (a) (list a gval))
                        args)))))

(defmacro nilf (&rest args) `(allf nil ,@args))

(defmacro tf (&rest args) `(allf t ,@args))

(defmacro toggle (&rest args)
  `(progn
     ,@(mapcar #'(lambda (a) `(toggle2 ,a))
                args)))

(define-modify-macro toggle2 () not)
\end{FramedVerb}\end{center}
\caption{汎変数に対して機能するマクロ．}
\label{fig:MacrosOnGnrlVars}
\end{figure}

第\ref{fig:MacrosOnGnrlVars}には，\verb|setf|の上に定義した新しいマクロを4個示した．
最初の\verb|allf|は，複数の汎変数を同じ値に設定するためのものだ．
さらにその上に\verb|nilf|と\verb|tf|が作られた．
これらは引数をそれぞれ\verb|nil|と\verb|t|に設定する．
これらは単純なマクロだが，プログラムに大きな違いを生む．

\verb|setq|と同様，\verb|setf|も複数の引数を取ることができる．
すなわち他に設定したい変数と値の組だ．
\begin{verbatim}
(setf x 1 y 2)
\end{verbatim}
これらのユーティリティも同様だが，半分の引数を省略することもできる．
複数の変数を\verb|nil|に設定したいときは，
\begin{verbatim}
(setf x nil y nil z nil)
\end{verbatim}
ではなく，ただこうすればよい．
\begin{verbatim}
(nilf x y z)
\end{verbatim}

最後のマクロ\verb|toggle|は前の節で説明した．
これは\verb|nilf|と似ているが，それぞれの引数に逆の真理値を与える．

これら4個のマクロは代入用オペレータに関する重要な点をはっきり表している．
オペレータを普通の変数のみに対して使うつもりでも，
\verb|setq|でなく\verb|setf|に展開されるマクロを書いた方がよいということだ．
第1引数がシンボルならば\verb|setf|は結局\verb|setq|に展開されるのだ．
\verb|setf|の一般性をなんの引替もなく享受できるのだから，
マクロ展開では\verb|setq|を使う方が好ましいことはまずないだろう．

\begin{figure}\begin{center}\begin{FramedVerb}
(define-modify-macro concf (obj) nconc)

(define-modify-macro conc1f (obj)
  (lambda (place obj)
    (nconc place (list obj))))

(define-modify-macro concnew (obj &rest args)
  (lambda (place obj &rest args)
    (unless (apply #'member obj place args)
      (nconc place (list obj)))))
\end{FramedVerb}\end{center}
\caption{汎変数に対するリスト操作．}
\label{fig:ListOpOnGnrlVars}
\end{figure}

第\ref{fig:ListOpOnGnrlVars}図にはリスト末尾を破壊的に操作するマクロを3個示した．
第3.1節では副作用を期待して
\begin{verbatim}
(nconc x y)
\end{verbatim}
を使うことは安全ではなく，代わりにこうしなければならないことに触れた．
\begin{verbatim}
(setq x (nconc x y))
\end{verbatim}

この慣用法は\verb|concf|の中に埋め込まれている．
更に特化した\verb|conc1f|と\verb|concnew|とは，
それぞれ\verb|push|と\verb|pushnew|とをリストの逆方向に使うようなものだ．
\verb|conc1f|は1個の要素をリスト末尾に追加する．
\verb|concnew|は同様だが要素が既に含まれていないときに限る．

第2.2節で，関数名はシンボルの他に$\lambda$式であってもよいと書いた．
そのため\verb|conc1f|の定義のように，
$\lambda$式を丸ごと\verb|define-modify-macro|の第3引数に使っても結構だ．
ertページの\verb|conc1|を使えば，このマクロは次のようにも書ける．
\begin{verbatim}
(define-modify-macro conc1f (obj) conc1)
\end{verbatim}

第\ref{fig:ListOpOnGnrlVars}図のマクロはある留保の元で使うべきだ．
すなわち，末尾に要素を追加していってリストを作ろうと思っているのなら，
\verb|push|を使い，最後にリストを\verb|nreverse|でインヴァージョンする方が好ましいという点だ．
リストの先頭に何か操作を行う方が，末尾に行うよりも楽に済む．
末尾に操作を行うには，まずそこまで到達しなければならないからだ．
Common Lispに前者を行うオペレータが多く，後者のためのものが少ないのは，
おそらく効率的なプログラミングを励行するためだろう．
%}}}
\subsection{更に複雑なユーティリティ}   %{{{
\verb|define-modify-macro|だけで\verb|setf|の上にどんなマクロも構築できるわけではない．
例えば，汎変数に破壊的に関数を適用するマクロ\verb|f|を定義したいとしよう．
組込みマクロ\verb|incf|は，\verb|+| に\verb|setf|を使うことの省略だ．
次のようにしなくとも，
\begin{verbatim}
(setf x (+ x y))
\end{verbatim}
ただこうすればよい．
\begin{verbatim}
(incf x y)
\end{verbatim}

新しく作る\verb|f|はこの考えの一般化だ．
\verb|incf|は \verb|+| の呼び出しに展開されるが，
\verb|f|は第1引数として渡されたオペレータの呼び出しに展開される．
例えばcvbページの\verb|scale-objs|の定義では，こう書かなければならなかった．
\begin{verbatim}
(setf (obj-dx o) (* (obj-dx o) factor))
\end{verbatim}
\verb|f|を使えば，これは次のようになる．
\begin{verbatim}
(_f * (obj-dx o) factor)
\end{verbatim}

\verb|f|の定義で犯す誤りは，次のようなものだろう．
\begin{verbatim}
(defmacro _f (op place &rest args)          ; 誤り
  `(setf ,place (,op ,place ,@args)))
\end{verbatim}
残念だが，\verb|define-modify-macro|では適切に\verb|f|を定義することはできない．
それは汎変数に適用されるオペレータが引数として与えられるからだ．

このように更に複雑なマクロは手作りで定義しなければならない．
そういったマクロを書き易くするため，Common Lispは関数\verb|get-setf-method|を提供している．
これは汎変数を取り，その値を取得または設定するために必要な全ての情報を返すものだ．
次の式を手で展開することで，この情報の使い方を示す．
\begin{verbatim}
(incf (aref a (incf i)))
\end{verbatim}

\verb|get-setf-method|を汎変数に対して呼び出すと，マクロ展開内での使うための値が5個返される．
\begin{verbatim}
> (get-setf-method '(aref a (incf i)))
(#:G4 #:G5)
(A (INCF I))
(#:G6)
(SYSTEM:SET-AREF #:G6 #:G4 #:G5)
(AREF #:G4 #:G5)
\end{verbatim}
最初の2個の値は，一時変数とそれに代入するべき値のリストだ．
だから展開形を次のように始めることができる．
\begin{verbatim}
(let* ((#:g4 a)
            (#:g5 (incf i)))
   ...)
\end{verbatim}

一般的な状況では値の式は先に出てきた式を参照しているかも知れないので，
これらの束縛は\verb|let*| 内で作られるべきだ．
3番目と
\footnote{第3の値は現在のところ常に1要素から成るリストだ．
これがリストとして与えられるのは，
汎変数に複数の値を蓄える（これまでのところ実現されていない）可能性を提供するためだ．}
5番目の値は，別の一時変数と汎変数の元の値を返す式だ．
この値に1を加えたいので，後者を \verb|1+| の呼び出し内に入れる．
\begin{verbatim}
(let* ((#:g4 a)
            (#:g5 (incf i))
            (#:g6 (1+ (aref #:g4 #:g5))))
   ...)
\end{verbatim}

最後に\verb|get-setf-method|の返す4番目の値とは，
新しい束縛のスコープ内で行われなければならない代入操作だ．
\begin{verbatim}
(let* ((#:g4 a)
            (#:g5 (incf i))
            (#:g6 (1+ (aref #:g4 #:g5))))
   (system:set-aref #:g6 #:g4 #:g5))
\end{verbatim}

この式はCommon Lispの一部ではない内部関数を参照していることの方が多い．
普通\verb|setf|はそれらの存在を隠蔽しているが，それらはどこかに存在していなければならない．
それに関することはみな実装依存なので，
可搬性を持たせたいコードでは\verb|system:set-aref|のような関数を直接参照せず，
\verb|get-setf-method|の返した値を使ようにするべきだ．

さて\verb|f|を実装するためには，
\verb|incf|を手で展開するときに行ったこととほとんど同じことを行うマクロを書くことになる．
唯一の違いは，\verb|let*| 内の最後の式を\verb|1+| の呼び出しの中に入れるのではなく，
\verb|f|の引数から作られた式の中に入れることだ．
\verb|f|の定義は第\ref{fig:MoreComplexMacrosOnSetf}図に示したようになる．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro _f (op place &rest args)
  (multiple-value-bind (vars forms var set access)
    (get-setf-method place)
    `(let* (,@(mapcar #'list vars forms)
             (,(car var) (,op ,access ,@args)))
       ,set)))

(defmacro pull (obj place &rest args)
  (multiple-value-bind (vars forms var set access)
    (get-setf-method place)
    (let ((g (gensym)))
      `(let* ((,g ,obj)
              ,@(mapcar #'list vars forms)
              (,(car var) (delete ,g ,access ,@args)))
         ,set))))

(defmacro pull-if (test place &rest args)
  (multiple-value-bind (vars forms var set access)
    (get-setf-method place)
    (let ((g (gensym)))
      `(let* ((,g ,test)
              ,@(mapcar #'list vars forms)
              (,(car var) (delete-if ,g ,access ,@args)))
         ,set))))

(defmacro popn (n place)
  (multiple-value-bind (vars forms var set access)
    (get-setf-method place)
    (with-gensyms (gn glst)
                  `(let* ((,gn ,n)
                          ,@(mapcar #'list vars forms)
                          (,glst ,access)
                          (,(car var) (nthcdr ,gn ,glst)))
                     (prog1 (subseq ,glst 0 ,gn)
                       ,set)))))
\end{FramedVerb}\end{center}
\caption{\texttt{setf}の上に作る更に複雑なマクロ．}
\label{fig:MoreComplexMacrosOnSetf}
\end{figure}
\begin{verbatim}
\end{verbatim}

このユーティリティはとても便利なものだ．
今これが手に入ったので，
例えば名前を持った関数ならメモワイズ技法（第5.3節）を適用したものと簡単に置き換えることができる
\footnote{しかし組込み関数にはこの方法でメモワイズ機能を付けるべきではない．
Common Lispは組込み関数の再定義を禁じている．}．
\verb|foo|をメモワイズ機能付きにするには，このようにすればよい．
\begin{verbatim}
(_f memoize (symbol-function 'foo))
\end{verbatim}

\verb|f|を利用すると，\verb|setf|の上に他のマクロを定義することも簡単になる．
例えば\verb|conc1f|（第\ref{fig:ListOpOnGnrlVars}図）は次のように定義できる．
\begin{verbatim}
(defmacro conc1f (lst obj)
   `(_f nconc ,lst (list ,obj)))
\end{verbatim}

第\ref{fig:MoreComplexMacrosOnSetf}図には\verb|setf|の上に構築した便利なマクロを他にも示した．
2番目の\verb|pull|は，組込み関数\verb|pushnew|のコンプリメント(complement)として意図されている．
これら2つは，\verb|push|と\verb|pop|が一層明確になったようなものだ．
\verb|pushnew|はオブジェクトが既にリストのメンバでないときだけそれをリストにプッシュし，
\verb|pull|は選択された要素をリストから破壊的に削除する．
\verb|pull|の定義内の\verb|&rest|パラメータにより，
\verb|pull|は\verb|delete|と同じキーワード引数を受け付けるようになっている．
\begin{verbatim}
> (setq x '(1 2 (a b) 3))
(12(AB)3)
> (pull 2 x)
(1 (A B) 3)
> (pull '(a b) x :test #'equal)
(1 3)
>x
(1 3)
\end{verbatim}

このマクロはあたかも次のように定義されたかのように考えられる．
\begin{verbatim}
(defmacro pull (obj seq &rest args)                       ; 誤り
   `(setf ,seq (delete ,obj ,seq ,@args)))
\end{verbatim}
しかしこう定義すると評価順と評価回数の両方に関して問題が生じる．
単純に\verb|modify-macro|で定義した\verb|pull|も作れる．
\begin{verbatim}
(define-modify-macro pull (obj &rest args)
   (lambda (seq obj &rest args)
        (apply #'delete obj seq args)))
\end{verbatim}
しかし\verb|modify-macros|は汎変数を第1引数として取らなければならないので，
第1，第2引数を逆順に与えなければならないが，これはやや直観に反する．

更に一般的な\verb|pull-if|は関数を引数に取り， \verb|delete|でなく\verb|delete-if|に展開される．
\begin{verbatim}
> (let ((lst '(1 2 3 4 5 6)))
        (pull-if #'oddp lst)
        lst)
(2 4 6)
\end{verbatim}

これら2つのマクロからは，一般的なポイントが他にも分かる．
基盤となる関数がオプショナル引数をとるときは，その上に構築されたマクロもそうなるべきだという点だ．
\verb|pull|と\verb|pull-if|は両方ともオプショナル引数を内部の\verb|delete|に渡すようになっている．

第\ref{fig:MoreComplexMacrosOnSetf}図の最後のマクロ\verb|popn|は，\verb|pop|の一般化だ．
リストに1要素だけをポップするのではなく，任意の部分リストをポップして返す．
\begin{verbatim}
> (setq x '(a b c d e f))
(ABCDEF)
> (popn 3 x)
(ABC)
>x
(DEF)
\end{verbatim}

第\ref{fig:MacroWhichSortsArgs}には引数を整列させるマクロを示した．
\verb|x|と\verb|y|が変数で，\verb|x|の値の方が小さくはないようにしたいときは，こうすればよい．
\begin{verbatim}
(if (> y x) (rotatef x y))
\end{verbatim}
しかしこれを3個以上の変数について行おうとすると，コードはたちまち肥大化する．
これを手で書く代わりに，\verb|sortf|に書かせることができる．
このマクロは比較オペレータと任意個の汎変数を取り，
それらの値がオペレータによって指定された順に並ぶまで値を入れ換える．
一番単純な場合では，引数は普通の変数になる．
\begin{verbatim}
> (setq x 1 y 2 z 3)
3
> (sortf > x y z)
3
> (list x y z)
(3 2 1)
\end{verbatim}

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro sortf (op &rest places)
  (let* ((meths (mapcar #'(lambda (p)
                            (multiple-value-list
                              (get-setf-method p)))
                        places))
         (temps (apply #'append (mapcar #'third meths))))
    `(let* ,(mapcar #'list
                    (mapcan #'(lambda (m)
                                (append (first m)
                                        (third m)))
                            meths)
                    (mapcan #'(lambda (m)
                                (append (second m)
                                        (list (fifth m))))
                            meths))
       ,@(mapcon #'(lambda (rest)
                      (mapcar
                        #'(lambda (arg)
                            `(unless (,op ,(car rest) ,arg)
                               (rotatef ,(car rest) ,arg)))
                        (cdr rest})))
                  temps)
       ,@(mapcar #'fourth meths))))
\end{FramedVerb}\end{center}
\caption{引数を整列させるマクロ．}
\label{fig:MacroWhichSortsArgs}
\end{figure}
\begin{verbatim}
\end{verbatim}

一般的には，それらは任意のインヴァージョン可能な式であってよい．
ここで\verb|cake|が誰かのケーキの取り分を返すインヴァージョン可能な関数であり，
\verb|bigger|がケーキに関して定義された比較関数だとしよう．
\verb|moe|のケーキは少なくとも\verb|larry|のケーキ程はあり，
それは少なくとも\verb|curly|のケーキ程はあるという規則を立てたいならば，こうすればよい．
\begin{verbatim}
(sortf bigger (cake 'moe) (cake 'larry) (cake 'curly))
\end{verbatim}

\verb|sortf|の定義は，概形としては\verb|f|の定義に似ている．
最初に\verb|let*| があり，\verb|get-setf-method|の返した一時変数が汎変数の初期値に束縛される．
\verb|sortf|の中核は真中の式\verb|mapcon|であり，これがその一時変数を整列させるためのコードを生成する．
マクロのこの部分が生成するコードは引数の数に関して指数的に増大する．
整列の後，\verb|get-setf-method|の返した式を使って汎変数に再び値が代入される．
使われているアルゴリズムは$O(n^2)$オーダのバブル・ソートだが，
このマクロは大量の引数について呼ばれることを意図したものではない．

\begin{figure}\begin{center}
\fbox{~\,\begin{minipage}{\FrameWidth}\narrowbaselines
\vspace{3pt}
\begin{center}\begin{minipage}{240pt}\texttt{%
(sortf > x (aref ar (incf i)) (car lst))
}\end{minipage}\end{center}
\hspace{12zw}は（ある処理系では）次のように展開される：
\begin{center}\begin{minipage}{240pt}\texttt{%
(let* ((\#:g1 x)\\
~~~~~~~(\#:g4 ar)\\
~~~~~~~(\#:g3 (incf i))\\
~~~~~~~(\#:g2 (aref \#:g4 \#:g3))\\
~~~~~~~(\#:g6 lst)\\
~~~~~~~(\#:g5 (car \#:g6)))\\
~~(unless (> \#:g1 \#:g2)\\
~~~~(rotatef \#:g1 \#:g2))\\
~~(unless (> \#:g1 \#:g5)\\
~~~~(rotatef \#:g1 \#:g5))\\
~~(unless (> \#:g2 \#:g5)\\
~~~~(rotatef \#:g2 \#:g5))\\
~~(setq x \#:g1)\\
~~(system:set-aref \#:g2 \#:g4 \#:g3)\\
~~(system:set-car \#:g6 \#:g5))
}\end{minipage}\end{center}
\vspace{1.3em}\end{minipage}~\,}\end{center}
\caption{\texttt{sortf}の呼び出しの展開形．}
\label{fig:ExpansionOfSortf}
\end{figure}

第\ref{fig:ExpansionOfSortf}図には，\verb|sortf|の呼び出しの展開形を示した．
最初の\verb|let*| で，引数とその部分式が注意深く左から右の順に評価される．
そしてその次の3個の式で一時変数の値を比較し，場合によっては値を入れ換える．
第1の一時変数が第2と比較され，次に第1と第3が比較され，次に第2と第3が比較される．
最後に汎変数は左から右の順に再代入を受ける．
問題になることは滅多にないが，マクロの引数は評価と同様に普通は左から右の順で値を代入されるべきだ．

\verb|f|や\verb|sortf|等のオペレータには，関数の引数を取る関数とのある種の類似性がある．
しかしこれらは全く違ったものとして理解されるべきだ．
\verb|find-if|のような関数は関数を取ってそれを呼び出す．
\verb|f|のようなマクロは関数の名前を取り，それを式のcar部に置く．
\verb|f|と\verb|sortf|は共に関数の引数を取るように書くこともできた．
例えば\verb|f|を次のように書いて，
\begin{verbatim}
(defmacro _f (op place &rest args)
  (let ((g (gensym)))
    (multiple-value-bind (vars forms var set access)
      (get-setf-method place)
      `(let* ((,g ,op)
              ,@(mapcar #'list vars forms)
              (,(car var) (funcall ,g ,access ,@args)))
         ,set))))
\end{verbatim}
\verb|(f #'+ x 1)|として呼び出すこともできた．
しかし元の\verb|f|はこれができることを全てできるし，扱うものが名前なのでマクロや特殊式の名前も受け付ける．
\verb|+|の他にも，例えば\verb|nif|（rtyページ）も使える．
\begin{verbatim}
> (let ((x 2))
    (_f nif x 'p 'z 'n)
    x)
P
\end{verbatim}
%}}}
\subsection{インヴァージョンを定義する}   %{{{
第12.1節ではインヴァージョン可能な参照に展開される任意のマクロ呼び出しは，
それ自身がインヴァージョン可能だということを説明した．
しかし，オペレータをインヴァージョン可能にするだけのためにそれをマクロとして定義する必要はない．
\verb|defsetf|を使えば，Lispに任意の関数やマクロ呼び出しをインヴァージョンする方法を教えることができる．

このマクロの使い方は2通りある．
一番単純な場合では，引数は2個のシンボルになる．
\begin{verbatim}
(defsetf symbol-value set)
\end{verbatim}

複雑な形では，\verb|defsetf|の呼び出しは\verb|defmacro|の呼び出しと似たようなものになり，
更新された値の式のための仮引数が加わる．
例えば，次のようにして\verb|car|に対するインヴァージョンを定義できる．
\begin{verbatim}
(defsetf car (lst) (new-car)
   `(progn (rplaca ,lst ,new-car)
           ,new-car))
\end{verbatim}

\verb|defmacro|と\verb|defsetf|には，重要な違いが1個ある．
後者は引数のために自動的にgensymを生成する点だ．
上の定義の下では，\verb|(setf (car x) y)|は次のように展開されるだろう．
\begin{verbatim}
(let* ((#:g2 x)
       (#:g1 y))
  (progn (rplaca #:g2 #:g1)
         #:g1))
\end{verbatim}
そのため変数捕捉及び評価の回数や順番に煩わされずに\verb|defsetf|の展開関数を書くことができる．

\begin{figure}\begin{center}\begin{FramedVerb}
(defvar *cache* (make-hash-table))

(defun retrieve (key)
  (multiple-value-bind (x y) (gethash key *cache*)
    (if y(values x y)
        (cdr (assoc key *world*)))))

(defsetf retrieve (key) (val)
  `(setf (gethash ,key *cache*) ,val))
\end{FramedVerb}\end{center}
\caption{非対称なインヴァージョン．}
\label{fig:AsymmetricInversion}
\end{figure}

\textsf{CLtL2}準拠のCommon Lispでは，
\verb|setf|に対するインヴァージョンを\verb|defun|で直接定義できる．
よって上の例は次のようにも書ける．
\begin{verbatim}
(defun (setf car) (new-car lst)
  (rplaca lst new-car)
  new-car)
\end{verbatim}
このような関数では，更新された値が第1引数になるべきだ．
また，この値を関数の値として返すことも慣習になっている．

これまでの例では汎変数とはデータ構造内の場所を参照するためのものかのように示唆してきた．
悪者が人質を地下迷宮の中に連れ去ると，彼女を救うヒーローは外に連れ出すことになる．
悪者もヒーローも同じ道を通るが，その方向は逆だ．
\verb|setf|がこのように動作しなければならないという印象を持たれても驚きはしない．
定義済みのインヴァージョンは全てこの形式になっているようだからだ．
実際は，「場所」はインヴァージョンを受ける仮引数に対する慣用名に過ぎない．

原則的には，\verb|setf|はもっと一般的なものだ．
アクセス用の式とそのインヴァージョンは同じデータ構造に対して働く必要すらない．
何かのアプリケーションで，データベースの更新をキャッシュしたいとしよう．
これが必要になるのは，例えば動作中に実際に更新を行うのが非効率的だったり，
一貫性を保つために更新点をコミット前に検証しなければならないときだ．

\verb|*world*| が実際のデータベースだとしよう．
単純化のため，これはalistで，
その要素は\verb|(|$\langle$キー$\rangle$ \verb|.| $\langle$値$\rangle$\verb|)|という形式だとする．
第\ref{fig:AsymmetricInversion}図には\verb|retrieve|という名前の検索関数を示した．
\verb|*world*| が次の状態のときは，
\begin{verbatim}
((a . 2) (b . 16) (c . 50) (d . 20) (f . 12))
\end{verbatim}
次のように動作する．
\begin{verbatim}
> (retrieve 'c)
50
\end{verbatim}

\verb|car|の呼び出しと異なり，
\verb|retrieve|の呼び出しはデータ構造の特定の場所を参照しているのではない．
返り値は2箇所の場所のうちどちらかから得られることになる．
そして\verb|retrieve|のインヴァージョン（やはり第\ref{fig:AsymmetricInversion}図に示した）は，
その片方を参照するだけだ．
\begin{verbatim}
> (setf (retrieve 'n) 77)
77
> (retrieve 'n)
77
T
\end{verbatim}
この検索では第2の返り値\verb|t|が返るが，これは求める値がキャッシュ内に見つかったことを表す．

マクロそのものと同様に，汎変数も目覚しい力を持った抽象化手段だ．
その真価はここで語ったことに留まらないだろう．
個々の現場では汎変数の使用がエレガントで強力なプログラムにつながるような方法の方が
発見し易いことは確かだ．
しかし\verb|setf|のインヴァージョンを新しい方法で使ったり，
同様に便利な変換手法を発見することも可能かも知れない．
%}}}
%}}}
\section{コンパイル時の計算処理} %{{{
前の章ではマクロで実装しなければならないオペレータを何種類か論じた．
この章で論じる種類の問題は，関数でも解決できるが，マクロの方が効率的になるようなものだ．
第8.2節ではある状況においてマクロを使うことの長所と短所を列挙した．
長所の中には「コンパイル時の計算処理」というものがあった．
オペレータをマクロとして定義することで，
作業の一部をオペレータが展開されるときに行わせることができる場合がある．
この章ではこの可能性を活用するマクロを見ていく．
\subsection{新しいユーティリティ}   %{{{
第8.2章ではマクロを使って計算処理をコンパイル時に行わせる可能性を提起した．
そこでは例として，引数の平均値を返すマクロ\verb|avg|を定義した．
\begin{verbatim}
> (avg pi 4 5)
4.047...
\end{verbatim}
第\ref{fig:ShiftingComputation}図では\verb|avg|を最初は関数として，次にマクロとして定義した．
\verb|avg|がマクロとして定義されると，\verb|length|はコンパイル時に呼ばれることになる．
マクロ版では，実行時に\verb|&rest|パラメータを操作することの負担も回避している．
多くの処理系では\verb|avg|はマクロとして書いた方が速い．


\begin{figure}\begin{center}\begin{FramedVerb}
(defun avg (&rest args)
  (/ (apply #'+ args) (length args)))

(defmacro avg (&rest args)
  `(/ (+ ,@args) ,(length args)))
\end{FramedVerb}\end{center}
\caption{平均値を得るとき，計算処理をコンパイル時にずらす．}
\label{fig:ShiftingComputation}
\end{figure}

展開時に引数の数を知っていることから来るような類の処理の節約は，
\verb|in|（sdfページ）で得られるような処理の節約と組み合わせることができる．
そこでは幾つかの引数の評価すら回避できたのだった．
第\ref{fig:ShiftingAndAvoiding}図には2通りの\verb|most-of|を示した．
これは引数の過半数が真を返すならば真を返すものだ．
\begin{verbatim}
> (most-of t t t nil)
T
\end{verbatim}

\begin{figure}\begin{center}\begin{FramedVerb}
(defun most-of (&rest args)
  (let ((all 0)
        (hits 0))
    (dolist (a args)
      (incf all)
      (if a (incf hits)))
    (> hits (/ all 2))))

(defmacro most-of (&rest args)
  (let ((need (floor (/ (length args) 2)))
        (hits (gensym)))
    `(let ((,hits 0))
       (or ,@(mapcar #'(lambda (a)
                          `(and ,a (> (incf ,hits) ,need)))
                      args)))))
\end{FramedVerb}\end{center}
\caption{計算処理をコンパイル時にずらし，さらに回避する．}
\label{fig:ShiftingAndAvoiding}
\end{figure}

マクロ版は，\verb|in|と同様に，必要なだけの引数を評価するようなコードに展開される．
例えば\verb|(most-of (a)| \verb|(b) (c))|は次のような等価な式に展開される．
\begin{verbatim}
(let ((count 0))
     (or (and (a) (> (incf count) 1))
         (and (b) (> (incf count) 1))
         (and (c) (> (incf count) 1))))
\end{verbatim}
一番都合が良い場合には，ちょうど過半数の引数だけが評価される．

\begin{figure}\begin{center}\begin{FramedVerb}
(defun nthmost (n lst)
  (nth n (sort (copy-list lst) #'>)))

(defmacro nthmost (n lst)
  (if (and (integerp n) (< n 20))
      (with-gensyms (glst gi)
                    (let ((syms (map0-n #'(lambda (x) (gensym)) n)))
                      `(let ((,glst ,lst))
                         (unless (< (length ,glst) ,(1+ n))
                           ,@(gen-start glst syms)
                           (dolist (,gi ,glst)
                             ,(nthmost-gen gi syms t))
                           ,(car (last syms))))))
      `(nth ,n (sort (copy-list ,lst) #'>))))

(defun gen-start (glst syms)
  (reverse
    (maplist #'(lambda (syms)
                 (let ((var (gensym)))
                   `(let ((,var (pop ,glst)))
                      ,(nthmost-gen var (reverse syms)))))
             (reverse syms))))

(defun nthmost-gen (var vars &optional long?)
  (if (null vars)
      nil
      (let ((else (nthmost-gen var (cdr vars) long?)))
        (if (and (not long?) (null else))
            `(setq ,(car vars) ,var)
            `(if (> ,var ,(car vars))
                 (setq ,@(mapcan #'list
                                  (reverse vars)
                                  (cdr (reverse vars)))
                       ,(car vars) ,var)
                 ,else)))))
\end{FramedVerb}\end{center}
\caption{コンパイル時に分かっている引数の利用．}
\label{fig:UseOfArgsKnownAtCompileTime}
\end{figure}

マクロは特定の引数の値が知られているときにも，計算処理をコンパイル時にずらせるかも知れない．
第\ref{fig:UseOfArgsKnownAtCompileTime}図にはそのようなマクロの例を示した．
関数\verb|nthmost|は数\verb|n|と数からなるリストを取り，リスト内で\verb|n|番目に大きい数を返す．
他のシーケンス用関数と同様に，最初は0番目とされる．
\begin{verbatim}
> (nthmost 2 '(2 6 1 5 3 4))
4
\end{verbatim}
関数版はとても単純に書かれている．
それはリストを整列させ，それを引数に\verb|nth|を呼ぶ．
\verb|sort|は破壊的なので，\verb|nthmost|は整列前にリストをコピーしている．
このように定義されると，\verb|nthmost|は2点で非効率的になる．
コンシングを起こす点と，
関心があるのは大きい順に\verb|n|個までなのに引数のリスト全体を整列させる点だ．

\verb|n|がコンパイル時に分かっていれば，この問題には別の方法で取り組める．
第\ref{fig:UseOfArgsKnownAtCompileTime}図の後半ではマクロ版の\verb|nthmost|を定義した．
このマクロが最初に行うことは，第1引数を調べることだ．
第1引数が数定数でないときには，上で見たものと同じコードに展開される．
第1引数が数定数だと，別の手段に移る．
例えば皿の上の3番目に大きいクッキーを取りたいときは，
それぞれのクッキーを順番に眺め回し，
その間ずっとそれまでに見たクッキーの内の大きい順に3個を手に取っておけばよい．
全てのクッキーを見た後は，手の中の1番小さいクッキーが求めていたものだ．
\verb|n|が小さい定数で，クッキーの総数に比例しないならば，
この方法により，最初に全てのクッキーを整列させるときよりも少ない労力で求めるクッキーが手に入る．

\verb|n|が展開時に知られている場合にはこの戦略に従う．
上のマクロは展開中に\verb|n|個の変数を生成し，\verb|nthmost-gen|を呼んで，
それぞれのクッキーを見ているときに評価されなければならないコードを生成する．
第\ref{fig:ExpansionOfNthmost}図にはマクロ展開の例を示した．
マクロ\verb|nthmost|は元の関数と全く同じ動作をするが，\verb|apply|の引数として渡せない点が違っている．
マクロを使うことを正当化するのは，純粋に効率性という観点だ．
マクロ版は実行時にコンシングを起こさず，更に\verb|n|が小さい定数のときには比較回数が少なくて済む．

効率的なプログラムを得るには，このように大きなマクロを書くような骨折りが必要なのだろうか？
この場合には，恐らくそうではないだろう．
2通りの\verb|nthmost|は一般原則の例として意図されたものだ．
幾つかの引数がコンパイル時に知られているならば，マクロを使って効率のよいコードを生成できる．
恐らくこの可能性を利用するかどうかは，利益のためにどれ程の負担に耐えられるかということと，
効率的なマクロ版を書くためにどれ程の労力が必要かということに依る．
マクロ版の\verb|nthmost|は長く複雑なので，極端な状況でしか書く価値はないだろう．
しかしコンパイル時に得られる情報は，それを利用しないことに決めたときさえ含め，
常に考慮に値する要素なのだ．

\begin{figure}\begin{center}
\fbox{~\,\begin{minipage}{\FrameWidth}\narrowbaselines
\vspace{3pt}
\begin{center}\begin{minipage}{240pt}\texttt{%
(nthmost 2 nums)
}\end{minipage}\end{center}
\hspace{12zw}これは次のように展開される．
\begin{center}\begin{minipage}{260pt}\texttt{%
(let ((\#:g7 nums))\\
~~(unless (< (length \#:g7) 3)\\
~~~~(let ((\#:g6 (pop \#:g7)))\\
~~~~~~(setq \#:g1 \#:g6))\\
~~~~(let ((\#:g5 (pop \#:g7)))\\
~~~~~~(if (> \#:g5 \#:g1)\\
~~~~~~~~~~(setq \#:g2 \#:g1 \#:g1 \#:g5)\\
~~~~~~~~~~(setq \#:g2 \#:g5)))\\
~~~~(let ((\#:g4 (pop \#:g7)))\\
~~~~~~(if (> \#:g4 \#:g1)\\
~~~~~~~~~~(setq \#:g3 \#:g2 \#:g2 \#:g1 \#:g1 \#:g4)\\
~~~~~~~~~~(if (> \#:g4 \#:g2)\\
~~~~~~~~~~~~~~(setq \#:g3 \#:g2 \#:g2 \#:g4)\\
~~~~~~~~~~~~~~(setq \#:g3 \#:g4))))\\
~~~~(dolist (\#:g8 \#:g7)\\
~~~~~~(if (> \#:g8 \#:g1)\\
~~~~~~~~~~(setq \#:g3 \#:g2 \#:g2 \#:g1 \#:g1 \#:g8)\\
~~~~~~~~~~(if (> \#:g8 \#:g2)\\
~~~~~~~~~~~~~~(setq \#:g3 \#:g2 \#:g2 \#:g8)\\
~~~~~~~~~~~~~~(if (> \#:g8 \#:g3)\\
~~~~~~~~~~~~~~~~~~(setq \#:g3 \#:g8)\\
~~~~~~~~~~~~~~~~~~nil))))\\
~~~~\#:g3))
}\end{minipage}\end{center}
\vspace{1.3em}\end{minipage}~\,}\end{center}
\caption{\texttt{nthmost}の展開形．}
\label{fig:ExpansionOfNthmost}
\end{figure}
%}}}
\subsection{例：B\`ezier曲線}   %{{{
\verb|with-|系マクロ（第11.2節）と同様に，コンパイル時の処理のためのマクロは，
汎用ユーティリティとしてよりもある特定のアプリケーションのためのものとして書かれることが多い．
汎用ユーティリティは，コンパイル時にどれだけの情報を得られるだろうか？
それは与えられた引数の数と，場合によればそれらの値だ．
他の制約条件を使いたいならば，
それらはきっと個々のプログラムに課されたものでなければならないだろう．

例として，この章ではB\`ezier（ベジェ）曲線の生成がマクロによりどれだけ高速化できるかを示す．
B\`ezier曲線がインタラクティブに操作されるときは，高速に生成しなければならない．
曲線が幾つの部分から成るかがあらかじめ分かっているなら，
処理の大部分をコンパイル時に行えることが明らかになる．
曲線生成ルーチンをマクロとして書くことで，計算済みの値をコード内に織り込むことができる．
これより一般的な，値を配列に保持する最適化手法よりも，こちらの方が速いはずだ．

B\`ezier曲線は4個の点から定義される\wadash 2個の端点と2個の制御点だ．
2次元について考えるとき，
これらの点は曲線上の点のx座標とy座標を定める方程式の媒介変数表示を定義する．
2個の端点を (x0, y0) と (x3, y3) とし，2個の制御点を (x1, y1) と (x2, y2) とすると，
曲線上の点を定義する方程式は次のようになる．
\[
    x = (x_3 - 3x_2 + 3x_1 - x_0)u^3 + (3x_2 - 6x_1 + 3x_0)u^2 + (3x_1 - 3x_0)u + x_0
\] \[
    y = (y_3 - 3y_2 + 3y_1 - y_0)u^3 + (3y_2 - 6y_1 + 3y_0)u^2 + (3y_1 - 3y_0)u + y_0
\]

これらの方程式を$0$から$1$までの$u$の$n$個の値について評価すれば，
曲線上の点が$n$個得られる．
例えば曲線を20分割して表示したいときは，
上の方程式を$u = .05, .1,..., .95$について評価することになる．
方程式を$u=0$または$1$で評価する必要はない．
$u = 0$では開始端点$(x_0, y_0)$が，$u = 1$では終了端点$(x3, y3)$が得られるからだ．

明らかな最適化手段は，$n$を固定し，$u$，$u^2$\ldots をあらかじめ計算し，
そしてそれらを$(n-1) \times 3$配列に蓄えることだ．
曲線生成ルーチンをマクロとして定義することで，効率をずっと上げることができる．
$n$がコンパイル時に知られていれば，プログラムは曲線を描くコマンド$n$個に展開できる．
あらかじめ計算した$u$，$u^2$，\ldots は，配列に蓄えるのではなく，
マクロの展開形の中に定数値としてそのまま挿入できる．

\begin{figure}\begin{center}\begin{FramedVerb}
(defconstant *segs* 20)
(defconstant *du*       (/ 1-0 *segs*))
(defconstant *pts* (make-array (list (1+ *segs*) 2)))

(defmacro genbez (x0 y0 x1 y1 x2 y2 x3 y3)
  (with-gensyms (gx0 gx1 gy0 gy1 gx3 gy3)
                `(let ((,gx0 ,x0) (,gy0 ,y0)
                                  (,gx1 ,x1) (,gy1 ,y1)
                                  (,gx3 ,x3) (,gy3 ,y3))
                   (let ((cx (* (- ,gx1 ,gx0) 3))
                         (cy (* (- ,gy1 ,gy0) 3))
                         (px (* (- ,x2 ,gx1) 3))
                         (py (* (- ,y2 ,gy1) 3)))
                     (let ((bx (- px cx))
                           (by (- py cy))
                           (ax (- ,gx3 px ,gx0))
                           (ay (- ,gy3 py ,gy0)))
                       (setf (aref *pts* 0 0) ,gx0
                             (aref *pts* 0 1) ,gy0)
                       ,@(map1-n #'(lambda (n)
                                      (let* ((u (* n *du*))
                                             (u^2 (* u u))
                                             (u^3 (expt u 3)))
                                        `(setf (aref *pts* ,n 0)
                                               (+ (* ax ,u^3)
                                                  (* bx ,u^2)
                                                  (* cx ,u)
                                                  ,gx0)
                                               (aref *pts* ,n 1)
                                               (+ (* ay ,u^3)
                                                  (* by ,u^2)
                                                  (* cy ,u)
                                                  ,gy0))))
                                  (1- *segs*))
                       (setf (aref *pts* *segs* 0) ,gx3
                             (aref *pts* *segs* 1) ,gy3))))))
\end{FramedVerb}\end{center}
\caption{B\`ezier曲線を生成するためのマクロ．}
\label{fig:MacroForBezier}
\end{figure}

第\ref{fig:MacroForBezier}図にはこの戦略に基づく曲線生成マクロを示した．
これは曲線を即座に描くのではなく，生成した座標を配列に蓄える．
曲線がインタラクティブに動かされているときは，個々の曲線は2回ずつ描かれなければならない．
表示するために1回，そして次を描く前に消去するために（訳注：背景色で）1回だ．
その間，どこかに座標を保存しなければならない．

$n = 20$では，\verb|genbez|は21個の\verb|setf|に展開される．
$u$，$u^2$，\ldots はコード内に直接使われるので，
それらを実行時に配列から探す負担と，開始時に計算する負担が削減できる．
$u$，$u^2$，\ldots と同様に，配列のインデックスも展開形内には定数として現れるので，
\verb|(setf aref)|の範囲チェックもコンパイル時に行われる．
%}}}
\subsection{応用}   %{{{
この後の章にはコンパイル時に利用できる情報を活用するマクロが他にも幾つか載っている．
よい例は\verb|if-match| （cvnページ）だ．
パターンマッチャは，2つのシーケンス（変数を含んでよい）を比較し，
変数に値を代入して2つのシーケンスを等しくする方法があるかを調べる．
\verb|if-match|の構成は，シーケンスの片方がコンパイル時に分かっていて，
そちらだけが変数を含んでいるならば，マッチングを効率的に行えることを示している．
実行時に2つのシーケンスを比較し，
その間に生成された変数束縛を保持するリストを，コンシングで作り上げるのではなく，
分かっているシーケンスから決定される単純な比較を行うコードをマクロに生成させ，
束縛をLispの真の変数に蓄えることができる．

また第19-24章で説明する埋め込み言語も，コンパイル時に得られる情報を大部分で活用している．
埋め込み言語は一種のコンパイラなので，そのような情報を使うべきであるのは自然なことだ．
一般則としては，マクロは精巧であればある程，より多くの制約を引数に課すことになり，
これらの制約条件を効率的なコードの生成に利用できる確率が一層高まる．
%}}}
%}}}
\section{アナフォリックマクロ} %{{{
第9章では，変数捕捉をどれも問題として扱った\wadash
うっかりすると起きてしまい，プログラムに悪い影響だけを与えるものとして．
この章では変数捕捉は建設的にも使えることを示す．
それなしでは書けないような便利なマクロが幾つかあるのだ．

ある式が非\verb|nil|の値を返すかどうか調べ，
そうならば値に何かを行いたいようなことはLispプログラミングでは珍しくない．
式の評価に大きな負担がかかるならば，普通は次のようにしなければならないだろう．
\begin{verbatim}
(let ((result (big-long-calculation)))
  (if result
      (foo result)))
\end{verbatim}
日常言語と同じように，これを次のように表現できたら楽ではないだろうか？
\begin{verbatim}
(if (big-long-calculation)
     (foo it))
\end{verbatim}

変数捕捉を利用することで，まさにこのとおりに動作する\verb|if|の変種を定義できる．
\subsection{アナフォリックな変種オペレータ}   %{{{
日常言語では，アナフォラ（前方照応，anaphora）とは会話の中で前に出てきたことを指す表現のことだ．
英語で一番馴染み深いアナフォラは恐らく「それ」で，
「レンチを取ったら，それを机に置いてくれ」等と使われる
（訳注：日本語ではそもそも省かれるので例が不自然になってしまった）．
アナフォラは日常会話の中で大変便利なものだ\wadash それを使わないことを想像してみよう\wadash
しかしそれはプログラミング言語には出てこない
（訳注：PerlやRubyでは \verb|$_| で「最後に読み込んだ文字列」が表せる）．
ほとんどの局面では，それでいい．
アナフォリックな（前方照応的な，anaphoric）表現はしばしばひどく曖昧だが，
現代のプログラミング言語は曖昧性を扱うようには設計されていないからだ．

しかし非常に制限された形式のアナフォラを，曖昧さを入れずにLispプログラムに導入することは可能だ．
アナフォラは捕捉されたシンボルにそっくりだということが分かる．
代名詞として働くシンボルを作り，そしてそれらのシンボルを捕捉するマクロを意図的に書くことで，
アナフォラをプログラムに導入できる．

新型の\verb|if|では，シンボル\verb|it|が捕捉したいものだ．
アナフォリックな\verb|if|は簡潔に\verb|aif|と呼ぶことにするが，次のように定義され，
\begin{verbatim}
(defmacro aif (test-form then-form &optional else-form)
  `(let ((it ,test-form))
     (if it ,then-form ,else-form)))
\end{verbatim}
前の方の例と同じように使われる．
\begin{verbatim}
(aif (big-long-calculation)
  (foo it))
\end{verbatim}

\verb|aif|を使うときは，テスト節の返す結果にシンボル\verb|it|が束縛されたままになる．
上のマクロ呼び出しでは\verb|it|はフリーのように見えるが，
実際は式\verb|(foo it)|は\verb|aif|の展開に伴い，
シンボル\verb|it|に束縛のあるコード内に挿入される．
\begin{verbatim}
(let ((it (big-long-calculation)))
  (if it (foo it) nil))
\end{verbatim}
よってソースコード内ではフリーに見えるシンボルはマクロ展開によって束縛されたままになる．
この章で示すアナフォリックマクロは，全て同じ手法に基づくものだ．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro aif (test-form then-form &optional else-form)
  `(let ((it ,test-form))
     (if it ,then-form ,else-form)))

(defmacro awhen (test-form &body body)
  `(aif ,test-form
        (progn ,@body)))

(defmacro awhile (expr &body body)
  `(do ((it ,expr ,expr))
     ((not it))
     ,@body))

(defmacro aand (&rest args)
  (cond ((null args) t)
        ((null (cdr args)) (car args))
        (t `(aif ,(car args) (aand ,@(cdr args))))))

(defmacro acond (&rest clauses)
  (if (null clauses)
      nil
      (let ((cl1 (car clauses))
            (sym (gensym)))
        `(let ((,sym ,(car cl1)))
           (if ,sym
               (let ((it ,sym)) ,@(cdr cl1))
               (acond ,@(cdr clauses)))))))
\end{FramedVerb}\end{center}
\caption{Common Lispの標準オペレータのアナフォリックな変種．}
\label{fig:AnaphoricVariants}
\end{figure}

第\ref{fig:AnaphoricVariants}図には幾つかのCommon Lispオペレータのアナフォリックな変種を示した．
\verb|aif|の次の\verb|awhen|は，\verb|when|をアナフォリックにしたものだ．
\begin{verbatim}
(awhen (big-long-calculation)
  (foo it)
  (bar it))
\end{verbatim}

\verb|aif|も\verb|awhen|も頻繁に役立つが，
\verb|awhile|はアナフォリックでない\verb|while|（vgpページで定義された）より多く必要になるという点で
アナフォリックマクロの中では恐らくユニークなものだろう．
\verb|while|と\verb|awhile|のようなマクロは，
プログラムが外部データを監視する必要がある状況で使われるのが典型的だ．
そしてデータの監視を繰り返す間，それが状態を変化させるのをただ待っているのでなければ，
普通は得られたオブジェクトに対し何かを行いたいことだろう．
\begin{verbatim}
(awhile (poll *fridge*)
  (eat it))
\end{verbatim}

\verb|aand|の定義はそれまでのものより少々複雑になっている．
これはアナフォリックな\verb|and|を与える．
それぞれの引数の評価の間，\verb|it|はその前の引数が返した値に束縛される
\footnote{\texttt{and}と\texttt{or}は一緒にして考えられがちだが，
アナフォリックな\texttt{or}を書いても意味はないだろう．
\texttt{or}の引数が評価されるのは，それより前の引数が\texttt{nil}に評価されたときだけだ．
だから\texttt{aor}の中でアナフォリックシンボルを参照しても，何も便利なことはないだろう．}．
実用では，\verb|aand|は条件に基づいてクエリを発行するプログラムで使われることが多い．
\begin{verbatim}
(aand (owner x) (address it) (town it))
\end{verbatim}
これは\verb|x|の所有者の住所（所有者がいるならば）のある町（住所があるならば）
を返す（町があるならば）．
\verb|aand|なしでは，これは次のように書かなければならないだろう．
\begin{verbatim}
(let ((own (owner x)))
  (if own
      (let ((adr (address own)))
        (if adr (town adr)))))
\end{verbatim}

\verb|aand|の定義は，展開形がマクロ呼び出しの引数の数によって変わることを示している．
引数が0個のときは，\verb|aand|は普通の\verb|and|と同様にただ\verb|t|を返すだけだ．
そうでなければ展開形は再帰的に生成される．
再帰の段階毎に入れ子になった\verb|aif|の連鎖に新しい層が追加される．\\[4pt]
\texttt{(aif} $\langle$第1引数$\rangle$\\
~~~$\langle$引数の残り$\rangle$ \texttt{)}\\[4pt]

大部分の再帰関数が\verb|nil|を受け取る段階まで再帰を続けるのとは違い，
\verb|aand|の展開は引数が1個の時点で終結しなければならない．
選択肢が1個もない段階まで再帰が進み過ぎると，展開形は必ず次のような形になる．
\begin{verbatim}
(aif  c1
         ...(aif  cn t)...)
\end{verbatim}
このような式は必ず\verb|t|か\verb|nil|のどちらかを返すので，
上の例が意図した通りに動作しなくなる．

第10.4節で，マクロが常に自分の呼び出しを含む展開形を生成するようでは，
展開は永遠に終結しないと警告した．
\verb|aand|も再帰的だが，ベース・ケースでは展開形は\verb|aand|を参照しないので安全だ．

最後の\verb|acond|は，
\verb|cond|の節のテスト式以外でテスト式の返した値を使いたい場合のために作られた．
(この状況はとてもよく現れるので，
Schemeの処理系によっては\verb|cond|の節の中でテスト式の返した値を使う方法を提供している．)


\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro alambda (parms &body body)
  `(labels ((self ,parms ,@body))
     #'self))

(defmacro ablock (tag &rest args)
  `(block ,tag
     ,(funcall (alambda (args)
                 (case (length args)
                   (0 nil)
                   (1 (car args))
                   (t `(let ((it ,(car args)))
                         ,(self (cdr args))))))
               args)))
\end{FramedVerb}\end{center}
\caption{アナフォリックなオペレータの続き．}
\label{fig:MoreAnaphoricVariants}
\end{figure}


\verb|acond|の節の展開形の中では，テスト式の結果は最初にgensymに保持される．
これはシンボル\verb|it|が節の残りの部分でのみ束縛されるようにするためだ．
マクロが束縛を生成するときには，必ず可能なかぎり狭いスコープの中で生成するべきだ．
ここでgensymをけちって，代わりに次のように\verb|it|をテスト式の結果に直接束縛すると，
\begin{verbatim}
(defmacro acond (&rest clauses)              ; 誤り
  (if (null clauses)
      nil
      (let ((cl1 (car clauses)))
        `(let ((it ,(car cl1)))
           (if it
               (progn ,@(cdr cl1))
               (acond ,@(cdr clauses)))))))
\end{verbatim}
\verb|it|の束縛はその次のテスト式もスコープに含んでしまうだろう．

第\ref{fig:MoreAnaphoricVariants}図には標準オペレータのアナフォリックな変種の，
更に複雑なものを示した．
マクロ\verb|alambda|は書かれているままの再帰関数を参照するためのものだ．
書かれているままの再帰関数を参照したいときとはいつだろうか？
シャープクォート付き$\lambda$式を使えば書かれているままの関数にアクセスできる．
\begin{verbatim}
#'(lambda (x) (* x 2))
\end{verbatim}
しかし第2章で説明したように，単純な$\lambda$式だけでは再帰関数は表現できない．
代わりに\verb|labels|でローカル関数を定義しなければならない．
次の関数（ertページから再録）は，
\begin{verbatim}
(defun count-instances (obj lists)
  (labels ((instances-in (list)
             (if list
                 (+ (if (eq (car list) obj) 1 0)
                    (instances-in (cdr list)))
                 0)))
    (mapcar #'instances-in lists)))
\end{verbatim}
オブジェクトとリストを引数に取り，リストの要素毎にそのオブジェクトが幾つ現れたかを返す．
\begin{verbatim}
> (count-instances 'a '((a b c) (d a r p a) (d a r) (a a)))
(1 2 1 2)
\end{verbatim}

アナフォラを使えば書かれているままの再帰関数に相当するものが作れる．
マクロ\verb|alambda|は\verb|labels|を使ってそのようなものを作るので，
例えば階乗関数を表現するのに使える．
\begin{verbatim}
(alambda (x) (if (= x 0) 1 (* x (self (1- x)))))
\end{verbatim}

\verb|alambda|を使って\verb|count-instances|と等価なものが次のように定義できる．
\begin{verbatim}
(defun count-instances (obj lists)
  (mapcar (alambda (list)
            (if list
                (+ (if (eq (car list) obj) 1 0)
                   (self (cdr list)))
                0))
          lists))
\end{verbatim}

第\ref{fig:MoreAnaphoricVariants}，\ref{fig:AnaphoricVariants}図の
他のマクロは全て\verb|it|を捕捉するが，それらと異なり，
\verb|alambda|は\verb|self|を捕捉する．
\verb|alambda|は\verb|labels|に展開されるが，
その中では\verb|self|は定義されている関数自身に束縛されている．
\verb|alambda|は短いだけでなく，見慣れた$\lambda$式と似ており，
それを使っているコードを読み易くしている．

\verb|ablock|の定義では新しいマクロが使われている．
組み込み特殊式\verb|block|のアナフォリック版だ．
\verb|block|では引数は全て左から右の順に評価される．
\verb|ablock|でもそれは同じだが，それぞれの引数において変数\verb|it|は前の引数の値に束縛される．

このマクロは思慮を持って使うべきだ．
便利なこともあるが，\verb|ablock|はうまく関数的になれるはずのプログラムを命令的に変えてしまいがちだ．
次のコードは，残念ながら典型的な汚い例だ．
\begin{verbatim}
> (ablock north-pole
    (princ "ho ")
    (princ it)
    (princ it)
    (return-from north-pole))
ho ho ho
NIL
\end{verbatim}

意図的に変数捕捉を行うマクロが別のパッケージにエクスポートされるときにはいつでも，
捕捉されるシンボルもエクスポートすることが必要だ．
例えば\verb|aif|がエクスポートされるときにはいつでも\verb|it|もそうしなければならない．
そうしないとマクロ定義内の\verb|it|は
マクロ呼び出し内で使われている\verb|it|とは別のシンボルになってしまうだろう．
%}}}
\subsection{失敗}   %{{{
Common Lispではシンボル\verb|nil|には少なくとも3種類の役割がある．
まずなにより空リストであって，次のように働く．
\begin{verbatim}
> (cdr '(a))
NIL
\end{verbatim}

空リストの他に，\verb|nil|は次のように真理値の偽の表現にも使われる．
\begin{verbatim}
> (= 1 0)
NIL
\end{verbatim}

そして最後に，関数は\verb|nil|を返すことで失敗を表す．
例えば組み込み関数\verb|find-if|はリストの要素で何かの条件を満たす最初のものを返す．
そのような要素が見付からなければ，\verb|find-if|は\verb|nil|を返す．
\begin{verbatim}
> (find-if #'oddp '(2 4 6))
NIL
\end{verbatim}

残念なことに上の場合は，\verb|find-if|が検索に成功したが，
検索したものが\verb|nil|だった場合と区別がつかない．
\begin{verbatim}
> (find-if #'null '(2 nil 6))
NIL
\end{verbatim}

\verb|nil|で偽と空リストの両方を表現したところで，実用的には大きな問題は起きない．
実際，むしろ便利なこともある．
しかし\verb|find-if|のような関数の返した結果に曖昧性が生まれるので，
\verb|nil|で失敗も表現するのは困ったことだ．

失敗と返り値の\verb|nil|を区別する問題は，オブジェクトを検索する関数全てで現れる．
Common Lispはこの問題に3通りもの解決策を用意している．
（多値を返す方法の次に）最もよく使われる方法は，とりあえずリスト構造を返しておくことだ．
例えば\verb|assoc|で検索失敗を見分けるのには何の問題もない．
成功したときには\verb|assoc|はキーと値の対全体を返すからだ．
\begin{verbatim}
> (setq synonyms '((yes . t) (no . nil)))
((YES . T) (NO))
> (assoc 'no synonyms)
(NO)
\end{verbatim}

この方法に倣い，\verb|find-if|の曖昧性が心配なときは，\verb|member-if|を使うことにする．
これは条件を満たす要素だけを返すのではなく，それから始まる\verb|cdr|部全体を返す．
\begin{verbatim}
> (member-if #'null '(2 nil 6))
(NIL 6)
\end{verbatim}

多値が利用可能になって以来，この問題には新しい解決策が加わった．
第1返り値をデータに，第2返り値を成功／失敗の表現に使うのだ．
組み込み関数\verb|gethash|はそのように動作する．
これは常に2個の値を返すが，2番目は何かが見つかったかどうかを示すものだ．
\begin{verbatim}
> (setf edible                      (make-hash-table)
        (gethash 'olive-oil edible) t
        (gethash 'motor-oil edible) nil)
NIL
> (gethash 'motor-oil edible)
NIL
T
\end{verbatim}
だから起こり得る3通りの場合を全て判別したいなら，次のような慣用法が使える．
\begin{verbatim}
(defun edible? (x)
  (multiple-value-bind (val found?) (gethash x edible)
    (if found?
        (if val 'yes 'no)
        'maybe)))
\end{verbatim}
これによれば偽を失敗と区別するには次のようにすればよい．
\begin{verbatim}
> (mapcar #'edible? '(motor-oil olive-oil iguana))
(NO YES MAYBE)
\end{verbatim}

Common Lispでは失敗を表すのに3番目の方法が利用できる．
アクセス関数が，失敗のときに返すための特別なオブジェクト
（おそらくgensymを使うことになるだろう）を引数に取るようにすることだ．
この手法が使われている\verb|get|はオプショナルな引数を取り，
指定された属性が見つからなかったときにはそれを返す．
\begin{verbatim}
> (get 'life 'meaning (gensym))
#:G618
\end{verbatim}

多値を返せるときには，\verb|gethash|で使われている手法が一番きれいだ．
\verb|get|でしているように，
全てのアクセス関数にオプショナル引数を渡さなければならないようなことは避けたい．
そしてリストを使う手法と比べても，多値を使う方が一般性が高い．
\verb|find-if|は2個の値を返すように書き換えられるが，
\verb|gethash|はコンシングを起こさずに曖昧さを無くせるようなリスト構造を返すように
書き換えることはできない．
よって検索用の新関数を書くときや，失敗が起こり得る操作のためには，
普通は\verb|gethash|の手法に倣った方がよい．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro aif2 (test &optional then else)
  (let ((win (gensym)))
    `(multiple-value-bind (it ,win) ,test
       (if (or it ,win) ,then ,else))))

(defmacro awhen2 (test &body body)
  `(aif2 ,test
         (progn ,@body)))

(defmacro awhile2 (test &body body)
  (let ((flag (gensym)))
    `(let ((,flag t))
       (while ,flag
              (aif2 ,test
                    (progn ,@body)
                    (setq ,flag nil))))))

(defmacro acond2 (&rest clauses)
  (if (null clauses)
      nil
      (let ((cl1 (car clauses))
            (val (gensym))
            (win (gensym)))
        `(multiple-value-bind (,val ,win) ,(car cl1)
           (if (or ,val ,win)
               (let ((it ,val)) ,@(cdr cl1))
               (acond2 ,@(cdr clauses)))))))
\end{FramedVerb}\end{center}
\caption{多値を返すアナフォリックマクロ．}
\label{fig:Multiple-valueAnaphoricMacros}
\end{figure}

\verb|edible?|で使われている慣用法は正にマクロで隠蔽できる類の事務的処理だ．
\verb|gethash|等のアクセス関数に対しては，
同じ式の真偽を調べて結果を束縛するのでなく，
第1引数を調べて第2引数を束縛するように\verb|aif|を改変したものが欲しくなる．
新しい\verb|aif|を\verb|aif2|と名付けるが，
それを第\ref{fig:Multiple-valueAnaphoricMacros}図に示した．
これを使えば\verb|edible?|は次のように書ける．
\begin{verbatim}
(defun edible? (x)
  (aif2 (gethash x edible)
           (if it 'yes 'no)
           'maybe))
\end{verbatim}

第\ref{fig:Multiple-valueAnaphoricMacros}図には\verb|awhen|，
\verb|awhile|や\verb|acond|を同様に改変したものも示した．
\verb|acond2|の用例についてはeyoiページの\verb|match|の定義を参照．
このマクロなしでは遥かに長くなって対称性もなくなってしまう関数も，
このマクロを使えば\verb|cond|の形で表現できるようになる．

\begin{figure}\begin{center}\begin{FramedVerb}
(let ((g (gensym)))
  (defun read2 (&optional (str *standard-input*))
    (let ((val (read str nil g)))
      (unless (equal val g) (values val t)))))

(defmacro do-file (filename &body body)
  (let ((str (gensym)))
    `(with-open-file (,str ,filename)
       (awhile2 (read2 ,str)
                ,@body))))
\end{FramedVerb}\end{center}
\caption{ファイル用ユーティリティ．}
\label{fig:FileUtilities}
\end{figure}

組み込み関数\verb|read|は\verb|get|と同じ方法で失敗を表す．
これが取るオプショナル引数は\verb|eof|に出会ったときにエラーを起こすかどうか指定するものと，
起こさないときに返す値を指定するものだ．
第\ref{fig:FileUtilities}図に示した\verb|read|の別の定義は，第2返り値を使って失敗を表す．
\verb|read2|はが返す2個の値は，入力された式と，\verb|eof|のときに\verb|nil|になるフラグだ．
これは\verb|eof|のときに返されるgensym等を引数に\verb|read|を呼ぶが，
\verb|read2|が呼ばれる度にgensymを生成する負担を節約するため，
コンパイル時に生成されるgensymの独自コピーを持ったクロージャとして定義されている．

第\ref{fig:FileUtilities}図には，ファイル内の式について反復を行うための便利なマクロも示した．
これは\verb|awhile2|と\verb|read2|を使って定義されている．
\verb|do-file|を使うことで，例えば一種の\verb|load|を次のように定義できる．
\begin{verbatim}
(defun our-load (filename)
  (do-file filename (eval it)))
\end{verbatim}
%}}}
\subsection{参照の透明性}   %{{{
アナフォリックマクロは参照透明性を侵すと言われることがある．
GelernterとJagannathanは参照透明性を次のように定義した．
\begin{quotation}
    参照の透明性が保たれているプログラミング言語とは，\\
    a) どの部分式も，値の等しい別の式に置き換えることができ，\\
    b) 式は任意のコンテキスト内のどこで何回使われても同じ値を返す，ようなものだ．
\end{quotation}

この基準はプログラミング言語に適用されるもので，プログラムには適用されないことに注意しよう．
代入操作を持つプログラミング言語はいずれも参照透明性を持たない．
次の式で，最初と最後の\verb|x|は同じ値を持たない．
\begin{verbatim}
(list x (setq x (not x))
      x)
\end{verbatim}
これは\verb|setq|が介在しているからだ．
明らかに，これは汚いコードだ．
そのようなコードが可能であるという事実は，Lispは参照透明性を持たないということだ．

Norvigは，\verb|if|を次のように再定義したら便利だろうと述べたが，
\begin{verbatim}
(defmacro if (test then &optional else)
  `(let ((that ,test))
        (if that ,then ,else)))
\end{verbatim}
参照透明性を侵すという観点からこのマクロを却下している．

しかし問題は組み込みオペレータを再定義したことに因るもので，アナフォラを使ったことに因るのではない．
上の定義のb)節は，式が「任意のコンテキスト内」で必ず同じ値を返すことを要求している．
次の\verb|let|の中では，シンボル\verb|that|が新しい変数を表しても問題はない．
\begin{verbatim}
(let ((that 'which))
  ...)
\end{verbatim}
\verb|let|は当然新しいコンテキストを生成するはずのものだからだ．

上のマクロの問題は\verb|if|を再定義していることで，
そうすると新しいコンテキストが作られることにはならない．
アナフォリックマクロに別の名前を与えれば問題は消失する．
(それ以前に，\textsf{CLtL2}にあるように\verb|if|の再定義は違法だ．)
そのようなマクロが\verb|aif|の定義の一部であることにより，
そのマクロが生成したコンテキスト内では\verb|it|が新しい変数である限り，
そのマクロは参照透明性を侵さない．

さて\verb|aif|は確かに別の慣習に違反するが，それは参照透明性とは関係ない．
その慣習とは，新しく生成された変数は
ソースコード内で何らかの形で分かるようになっているべきというものだ．
上の\verb|let|は\verb|that|が新しい変数を参照するようになることをはっきり示している．
\verb|aif|内での\verb|it|の束縛がはっきり見えないという議論もあるかも知れない．
しかしこれは余り説得力のある意見ではない．
\verb|aif|は1個の変数を生成するだけだし，
しかもその変数を生成することだけが\verb|aif|を使う理由だからだ．

Common Lispそのものはこの慣習を不可侵なものとはしていない．
CLOS関数\verb|call-next-method|の束縛はコンテキストに依存するが，
これは\verb|aif|の本体内でシンボル\verb|it|がそうなのとと全く同様だ．
(\verb|call-next-method|をどのように実装するかについてのアイディアについては，
xwgページのマクロ\verb|defmeth|を参照．)
どの場合にしろ，そういった慣習はある目的のための手段と考えられているに過ぎない．
読み易いプログラムという目的だ．
そしてアナフォラは，英語を読み易くしてくれるのと全く同様に，確かにプログラムを読み易くしてくれる．
%}}}
%}}}
\section{関数を返すマクロ} %{{{
第5章では関数を返す関数の書き方を示した．
マクロはオペレータの組み合わせをずっと容易にしてくれる．
この章では第5章で定義したものと同じ抽象化構造を，
マクロを使ってきれいにかつ効率的に構築する方法を示す．
\subsection{関数の構築}   %{{{
$f$と$g$が関数ならば，$f\circ g(x)=f(g(x))$である．
第5.4節では，演算子$\circ$をLispの関数\verb|compose|として実装する方法を示した．
\begin{verbatim}
> (funcall (compose #'list #'1+) 2)
(3)
\end{verbatim}

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro fn (expr) `#',(rbuild expr))

(defun rbuild (expr)
  (if (or (atom expr) (eq (car expr) 'lambda))
      expr
      (if (eq (car expr) 'compose)
          (build-compose (cdr expr))
          (build-call (car expr) (cdr expr)))))

(defun build-call (op fns)
  (let ((g (gensym)))
    `(lambda (,g)
       (,op ,@(mapcar #'(lambda (f)
                           `(,(rbuild f) ,g))
                       fns)))))

(defun build-compose (fns)
  (let ((g (gensym)))
    `(lambda (,g)
       ,(labels ((rec (fns)
                      (if fns
                          `(,(rbuild (car fns))
                             ,(rec (cdr fns)))
                          g)))
          (rec fns)))))
\end{FramedVerb}\end{center}
\caption{汎用の関数生成マクロ．}
\label{fig:FuncBuildMacro}
\end{figure}

この章では，マクロによってよりよい関数生成オペレータを定義する方法について考える．
第\ref{fig:FuncBuildMacro}図には，汎用の関数生成オペレータ\verb|fn|を示した．
これは関数の仕様に基づいて合成関数を構築するもので，
\texttt{(\formal{オペレータ}~.~\formal{引数})}という形の式を引数に取る．
\formal{オペレータ}には関数またはマクロの名前か，特別扱いの\verb|compose|が指定できる．
\formal{引数}には1個の引数を取る関数またはマクロの名前か，\verb|fn|の引数になり得る式が入る．
例えば，
\begin{verbatim}
(fn (and integerp oddp))
\end{verbatim}
が生成する関数は次のものに等価だ．
\begin{verbatim}
#'(lambda (x) (and (integerp x) (oddp x)))
\end{verbatim}

\formal{オペレータ}に\verb|compose|を指定すると，\formal{引数}の合成になっている関数が得られる．
しかし\verb|compose|が関数として定義されていたときに必要だった\verb|funcall|は，
陽に使う必要がなくなっている．
例えば，
\begin{verbatim}
(fn (compose list 1+ truncate))
\end{verbatim}
は次のように展開される．
\begin{verbatim}
#'(lambda (#:g1) (list (1+ (truncate #:g1))))
\end{verbatim}
こうすると\verb|list|や\verb|1+|等の小さな関数のインライン・コンパイルが可能になる．
マクロ\verb|fn|は一般的な意味でのオペレータの名前を取る．
すなわち，次の例のように$\lambda$式も使える．
\begin{verbatim}
(fn (compose (lambda (x) (+ x 3)) truncate))
\end{verbatim}
これは次のように展開される．
\begin{verbatim}
#'(lambda (#:g2) ((lambda (x) (+ x 3)) (truncate #:g2)))
\end{verbatim}

ここで$\lambda$式として表現された関数は確かにインライン・コンパイルされることになる．
というのも\verb|compose|の引数として渡されたシャープクォート付き$\lambda$式は
\verb|funcall|されなければならないからだ．

第\ref{fig:FunctionBuilders}図には，\verb|fif|，\verb|fint|に\verb|fun|といった
3個の関数生成オペレータの定義を示した．
これらは汎用マクロ\verb|fn|に統合されることになる．
\verb|and|を\formal{オペレータ}に指定すると，\formal{引数}の関数の交わりが得られる．
\begin{verbatim}
> (mapcar (fn (and integerp oddp))
          '(c 3 p 0))
(NIL T NIL NIL)
\end{verbatim}
それに対し，\verb|or|では合併が得られる．
\begin{verbatim}
> (mapcar (fn (or integerp symbolp))
          '(c 3 p 0-2))
(T T T NIL)
\end{verbatim}
そして\verb|if|では本体が条件によって変わる関数が得られる．
\begin{verbatim}
> (map1-n (fn (if oddp 1+ identity)) 6)
(2 2 4 4 6 6)
\end{verbatim}

しかしこれら3個以外のLispの関数も利用できる．
\begin{verbatim}
> (mapcar (fn (list 1- identity 1+))
          '(1 2 3))
((0 1 2) (1 2 3) (2 3 4))
\end{verbatim}
そして\verb|fn|の\formal{引数}自体も式であってよい．
\begin{verbatim}
> (remove-if (fn (or (and integerp oddp)
                     (and consp cdr)))
             '(1 (a b) c (d) 2 3-4 (e f g)))
(C (D) 2 3-4)
\end{verbatim}

\verb|fn|に\verb|compose|を特別扱いさせても，それが強力になる訳ではない．
\verb|fn|の\formal{引数}を入れ子にすれば，関数の合成になるからだ．
例えば，
\begin{verbatim}
(fn (list (1+ truncate)))
\end{verbatim}
は次のように展開され，
\begin{verbatim}
#'(lambda (#:g1)
    (list ((lambda (#:g2) (1+ (truncate #:g2))) #:g1)))
\end{verbatim}
次と同様の動作になる．
\begin{verbatim}
(compose #'list #'1+ #'truncate)
\end{verbatim}

マクロ\verb|fn|が\verb|compose|を特別扱いするのは，その場合のコードを読み易くするためだけだ．
%}}}
\subsection{Cdr部での再帰}   %{{{
第5.5，5.6節では，再帰関数を生成する関数の書き方を示した．
ここからの2節では，そこで定義した関数に対して
アナフォリックマクロならどのようにきれいなインタフェースを提供できるかを示す．

第5.5節では，平坦なリストに対する再帰関数を生成する\verb|lrec|の定義方法を示した．
\verb|lrec|を使えば，次の関数\verb|our-every|を，
\begin{verbatim}
(defun our-every (fn lst)
  (if (null lst)
      t
      (and (funcall fn (car lst))
           (our-every fn (cdr lst)))))
\end{verbatim}
例えば\verb|oddp|に適用して呼び出すのは，次のように表現できる．
\begin{verbatim}
(lrec #'(lambda (x f) (and (oddp x) (funcall f)))
      t)
\end{verbatim}

ここでマクロが人生の面倒を取り除いてくれる．
再帰関数を表現するのに，指定しなければならない事柄はどれ程だろうか？
リストの現在のcar部と再帰呼び出しをアナフォラを使って
（それぞれ\verb|it|と\verb|rec|として）表現できたら，次のようにすればよくなる．
\begin{verbatim}
(alrec (and (oddp it) rec) t)
\end{verbatim}

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro alrec (rec &optional base)
  "cltl2 version"
  (let ((gfn (gensym)))
    `(lrec #'(lambda (it ,gfn)
               (symbol-macrolet ((rec (funcall ,gfn)))
                                ,rec))
           ,base)))

(defmacro alrec (rec &optional base)
  "cltl1 version"
  (let ((gfn (gensym)))
    `(lrec #'(lambda (it ,gfn)
               (labels ((rec () (funcall ,gfn)))
                 ,rec))
           ,base)))

(defmacro on-cdrs (rec base &rest lsts)
  `(funcall (alrec ,rec #'(lambda () ,base)) ,@lsts))
\end{FramedVerb}\end{center}
\caption{リストでの再帰のためのマクロ．}
\label{fig:MacrosForListRec}
\end{figure}

第\ref{fig:MacrosForListRec}図には，次のようなことを可能にしてくれるマクロの定義を示した．
\begin{verbatim}
> (funcall (alrec (and (oddp it) rec) t)
                 '(1 3 5))
T
\end{verbatim}
このマクロは，第2引数として与えられた式を\verb|lrec|に渡す関数に変換することで動作する．
第2引数はアナフォリックに\verb|it|や\verb|rec|を参照しているかもしれないので，
マクロの展開型内では，
関数の本体はそれらのシンボルが生成する束縛のスコープ内に置かれていなければならない．

実際には第\ref{fig:MacrosForListRec}図には2種類の\verb|alrec|の定義を示してある．
上の例で使った方にはシンボル・マクロ（第7.11節）が必要になる．
シンボル・マクロは最近のCommon Lispでしか使えないので，
第\ref{fig:MacrosForListRec}図には少々利便性の劣る\verb|alrec|も示した．
こちらでは\verb|rec|はローカル関数として定義されている．
関数にしたことの代償は，\verb|rec|を括弧で囲まなければならないという点だ．
\begin{verbatim}
(alrec (and (oddp it) (rec)) t)
\end{verbatim}
\verb|symbol-macrolet|を提供するCommon Lisp処理系では，元の方が好ましい．

Common Lispでは関数の名前空間が独立しているので，
これらの再帰関数生成マクロで名前のある関数を定義するとぎこちなくなってしまう．
\begin{verbatim}
(setf (symbol-function 'our-length)
      (alrec (1+ rec) 0))
\end{verbatim}
第\ref{fig:CommonLispFuncsDefinedWithOncdr}図の最後のマクロは，これを抽象化するためのものだ．
\verb|on-cdrs|を使えば，上の代わりに次のようにすればよい．
\begin{verbatim}
(defun our-length (lst)
  (on-cdrs (1+ rec) 0 lst))

(defun our-every (fn lst)
  (on-cdrs (and (funcall fn it) rec) t lst))
\end{verbatim}

\begin{figure}\begin{center}\begin{FramedVerb}
(defun our-copy-list (lst)
  (on-cdrs (cons it rec) nil lst))

(defun our-remove-duplicates (lst)
  (on-cdrs (adjoin it rec) nil lst))

(defun our-find-if (fn lst)
  (on-cdrs (if (funcall fn it) it rec) nil lst))

(defun our-some (fn lst)
  (on-cdrs (or (funcall fn it) rec) nil lst))
\end{FramedVerb}\end{center}
\caption{Common Lispの関数を\texttt{on-cdr}を使って定義した例．}
\label{fig:CommonLispFuncsDefinedWithOncdr}
\end{figure}

第\ref{fig:CommonLispFuncsDefinedWithOncdr}図には，
この真マクロを使って定義した既存のCommon Lispの関数を幾つか示した．
\verb|on-cdrs|を使って表現すると，これらの関数は最も基本的な形に還元される．
また，そうしなければ明らかにはならなかったこれらの関数の間の類似性にも気付かされる．

\begin{figure}\begin{center}\begin{FramedVerb}
(defun unions (&rest sets)
  (on-cdrs (union it rec) (car sets) (cdr sets)))

(defun intersections (&rest sets)
  (unless (some #'null sets)
    (on-cdrs (intersection it rec) (car sets) (cdr sets))))

(defun differences (set &rest outs)
  (on-cdrs (set-difference rec it) set outs))

(defun maxmin (args)
  (when args
    (on-cdrs (multiple-value-bind (mx mn) rec
               (values (max mx it) (min mn it)))
             (values (car args) (car args))
             (cdr args))))
\end{FramedVerb}\end{center}
\caption{\texttt{on-cdrs}を使って定義された新ユーティリティ．}
\label{fig:UtilsWithOnCdrs}
\end{figure}

第\ref{fig:UtilsWithOnCdrs}図には，
\verb|on-cdrs|を使って容易に定義される新ユーティリティを幾つか示した．
始めの3個，\verb|unions|，\verb|intersections|に\verb|differences|は，
それぞれ合併集合，共通集合に補集合を実装している．
Common Lispにはそれらの操作のための組み込み関数が備わっているが，
それらは1回に2つのリストしか引数に取れない．
そのため，3つのリストの合併を得るためには次のようにする必要がある．
\begin{verbatim}
> (union '(a b) (union '(b c) '(c d)))
(A B C D)
\end{verbatim}
新しく作った\verb|unions|は\verb|union|と同様に動作するが，任意個数の引数を取れる．
だから次のようにできる．
\begin{verbatim}
> (unions '(a b) '(b c) '(c d))
(D C A B)
\end{verbatim}
\verb|union|と同様に，\verb|unions|は要素の元のリスト内での順番を保たない．

Common Lisp組み込みの\verb|intersection|と，
より一般的な\verb|intersections|との関係もこれと同じだ．
\verb|intersections|の定義では，効率性のために最初に空引数を調べる動作が追加された．
集合の1つが空のときには，これは比較を省略する．

Common Lispには\verb|set-difference|という関数も備わっている．
これは2つのリストを引数に取り，1番目の要素だが，2番目の要素ではないものを返す．
\begin{verbatim}
> (set-difference '(a b c d) '(a c))
(D B)
\end{verbatim}
上の新ユーティリティでは，\verb|-|（マイナス）と同様に複数個の引数を扱える．
例えば\verb|(differences x y z)|は\verb|(set-difference x (unions y z))|と等価だ．
しかし後者に伴うコンシングが不必要になっている．
\begin{verbatim}
> (differences '(a b c d e) '(a f) '(d))
(B C E)
\end{verbatim}

これらの集合用オペレータは単なる例であって，実際に必要になることはない．
組み込み関数\verb|reduce|が既に扱っていた，
リストに対する再帰の特別な場合を代表しているに過ぎないからだ．
例えば次のようにする代わりに，
\begin{verbatim}
(unions ...)
\end{verbatim}
ただこうすればよい．
\begin{verbatim}
((lambda (&rest args) (reduce #'union args)) ...)
\end{verbatim}
しかし，一般的な状況では\verb|on-cdrs|の方が\verb|reduce|よりも強力だ．

recは値でなく呼び出しを参照するので，\verb|on-cdrs|を使って多値を返す関数を生成できる．
第\ref{fig:UtilsWithOnCdrs}図の最後の関数\verb|maxmin|はこの可能性を活用し，
リストを1回探索するうちに最大の要素と最小の要素の両方を発見する．
\begin{verbatim}
> (maxmin '(3 4 2 8 5 1 6 7))
8 1
\end{verbatim}

\verb|on-cdrs|はこの後の章で出てくるコードに使うこともできるだろう．
例えば\verb|compile-cmds|（ldqページ）は，
\begin{verbatim}
(defun compile-cmds (cmds)
      (if (null cmds)
           'regs
           `(,@(car cmds) ,(compile-cmds (cdr cmds)))))
\end{verbatim}
次のように簡潔に定義できる．
\begin{verbatim}
(defun compile-cmds (cmds)
      (on-cdrs `(,@it ,rec) 'regs cmds))
\end{verbatim}
%}}}
\subsection{部分ツリーでの再帰}   %{{{
リストに対する再帰へのマクロの応用は，ツリーに対する再帰にも適用できる．
この節では、マクロを使って第5.6節で定義したツリーに対する再帰関数への
よりきれいなインタフェースを定義する．

第5.6節では，ツリーに対する再帰関数を生成する関数を2つ定義した．
\verb|ttrav|は常にツリーの全体を探索するもので，
また\verb|trec|の方は複雑だが，再帰の停止を制御できるようになっている．
これらの関数を使えば，次の\verb|our-copy-tree|は，
\begin{verbatim}
(defun our-copy-tree (tree)
  (if (atom tree)
      tree
      (cons (our-copy-tree (car tree))
            (if (cdr tree) (our-copy-tree (cdr tree))))))
\end{verbatim}
こうして表現できる．
\begin{verbatim}
(ttrav #'cons)
\end{verbatim}
また次の\verb|rfind-if|の，
\begin{verbatim}
(defun rfind-if (fn tree)
  (if (atom tree)
      (and (funcall fn tree) tree)
      (or (rfind-if fn (car tree))
          (and (cdr tree) (rfind-if fn (cdr tree))))))
\end{verbatim}
例えば\verb|oddp|への適用は，こうして表現できる．
\begin{verbatim}
(trec #'(lambda (o l r) (or (funcall l) (funcall r)))
      #'(lambda (tree) (and (oddp tree) tree)))
\end{verbatim}

前節で\verb|lrec|に対してインタフェースを作ったのと同様，
アナフォリックマクロは\verb|trec|へのより良いインタフェースを作れる．
一般的な場合にも十分対処できるマクロは，以下の3つをアナフォリックに参照できるようでなければならない：
現在，対象となっているツリー（\verb|it|と呼ぶことにする），
左の部分ツリーに対する再帰（\verb|left|と呼ぶ），
そして右の部分ツリーに対する再帰（\verb|right|と呼ぶ）だ．
これらを慣習として定めれば，上に示した関数は新マクロを使って次のように表現できる．
\begin{verbatim}
(atrec (cons left right))

(atrec (or left right) (and (oddp it) it))
\end{verbatim}
第\ref{fig:MacrosForRecOnTree}図には，このマクロの定義を示した．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro atrec (rec &optional (base 'it))
  "cltl2 version"
  (let ((lfn (gensym)) (rfn (gensym)))
    `(trec #'(lambda (it ,lfn ,rfn)
               (symbol-macrolet ((left (funcall ,lfn))
                                 (right (funcall ,rfn)))
                                ,rec))
           #'(lambda (it) ,base))))

(defmacro atrec (rec &optional (base 'it))
  "cltl1 version"
  (let ((lfn (gensym)) (rfn (gensym)))
    `(trec #'(lambda (it ,lfn ,rfn)
               (labels ((left () (funcall ,lfn))
                        (right () (funcall ,rfn)))
                 ,rec))
           #'(lambda (it) ,base))))

(defmacro on-trees (rec base &rest trees)
  `(funcall (atrec ,rec ,base) ,@trees))
\end{FramedVerb}\end{center}
\caption{ツリーに対する再帰のためのマクロ．}
\label{fig:MacrosForRecOnTree}
\end{figure}

\verb|symbol-macrolet|をサポートしないLisp処理系では，
\verb|atrec|は第\ref{fig:MacrosForRecOnTree}図の2番目の形で定義できる．
こちらでは\verb|left|と\verb|right|をローカル関数として定義しているので，
\verb|our-copy-tree|は次のように表現される必要がある．
\begin{verbatim}
(atrec (cons (left) (right)))
\end{verbatim}

利便性のために，マクロ\verb|on-trees|も定義した．
これは前節の\verb|on-cdrs|に似ている．
第\ref{fig:FuncDefinedUsingOnTrees}図には，第5.6節の関数の\verb|on-trees|を使った定義を示した．

\begin{figure}\begin{center}\begin{FramedVerb}
(defun our-copy-tree (tree)
  (on-trees (cons left right) it tree))

(defun count-leaves (tree)
  (on-trees (+ left (or right 1)) 1 tree))

(defun flatten (tree)
  (on-trees (nconc left right) (mklist it) tree))

(defun rfind-if (fn tree)
  (on-trees (or left right)
            (and (funcall fn it) it)
            tree))
\end{FramedVerb}\end{center}
\caption{\texttt{on-trees}を使って定義した関数．}
\label{fig:FuncDefinedUsingOnTrees}
\end{figure}

第5章で注意したことだが，
そこで定義した再帰関数生成関数の構築した関数は末尾再帰的にはならない．
\verb|on-cdrs|や\verb|on-trees|を使って関数を定義すると，必ずしも最高の効率を持つ実装はできない．
基盤となっている\verb|trec|や\verb|lrec|と同様に，
これらのマクロは主にプロトタイプや，プログラム中で効率性が至上とされない部分で使うものだ．
しかしこの章と第5章の基盤となる考えは，
関数生成関数を書いて，それにマクロのきれいなインタフェースを被せることができるということだ．
これと同じ技法は，特に効率的なコードを生成する関数生成関数を構築するときにも同様に使える．
%}}}
\subsection{遅延評価}   %{{{


\begin{figure}\begin{center}\begin{FramedVerb}
(defconstant unforced (gensym))

(defstruct delay forced closure)

(defmacro delay (expr)
  (let ((self (gensym)))
    `(let ((,self (make-delay :forced unforced)))
       (setf (delay-closure ,self)
             #'(lambda ()
                 (setf (delay-forced ,self) ,expr)))
       ,self)))

(defun force (x)
  (if (delay-p x)
      (if (eq (delay-forced x) unforced)
          (funcall (delay-closure x))
          (delay-forced x))
      x))
\end{FramedVerb}\end{center}
\caption{\texttt{force}と\texttt{delay}の実装．}
\label{fig:ImplementationOfForceAndDelay}
\end{figure}

遅延評価とは，式を，値が必要になったときにのみ評価することだ．
遅延評価の使い道の1つは，遅延と呼ばれるオブジェクトを作ることだ．
遅延とは何らかの式の値を保持するもので，
式の値を，いつか後で必要になったときには確かに与えるという約束を表現する．
ところで約束はLispのオブジェクトなので，それが表現する値の目的の多くに対して役立つ．
そして式の値が必要になったときには，遅延が値を返すことができる．
Schemeには遅延の組み込みサポートがある．
Schemeのオペレータ\verb|force|と\verb|delay|は，
Common Lispでは\ref{fig:ImplementationOfForceAndDelay}図のように実装できる．
遅延は2個のメンバを持つ構造体\verb|delay|として表現される．
1番目のメンバはこの遅延がすでに評価されたかどうかを表し，評価されていたときにはその値を含む．
2番目のメンバはクロージャを含むが，これを呼ぶとこの遅延が表現する値が得られる．
マクロ\verb|delay|は式を引数に取り，その値を表現する遅延を返す．
\begin{verbatim}
> (let ((x 2))
    (setq d (delay (1+ x))))
#S(DELAY ...)
\end{verbatim}

遅延の中のクロージャを呼ぶことは，遅延に対して強制(force)を行うことと同じだ．
関数\verb|force|は任意のオブジェクトを引数に取る．
普通のオブジェクトに対しては，そのものを返す関数\verb|identity|として動作するが，
遅延に対しては，その遅延が表現する値の要求となる．
\begin{verbatim}
> (force 'a)
A
> (force d)
3
\end{verbatim}

\verb|force|は，遅延かも知れないオブジェクトを扱っているときにはいつでも使える．
例えば，遅延を含むかもしれないリストを整列させるときには，次のようにできる．
\begin{verbatim}
(sort lst #'(lambda (x y) (> (force x) (force y))))
\end{verbatim}

遅延をこのような裸の形で使うのはやや不便だ．
実際の応用現場では，更に抽象化の層を重ねて隠蔽することになるかも知れない．
%}}}
%}}}
\section{マクロを定義するマクロ} %{{{
コード内に生じたパターンは，しばしば新しい抽象化が必要であることを知らせてくれる．
このルールはマクロ自身のコードについても全く同じく当てはまる．
幾つかのマクロが似た形で定義されているときは，
マクロを定義するマクロを書いて，それらを生成させることができるかも知れない．
省略名を定義するマクロ，アクセス用マクロを定義するマクロ，
そして第14.1節で説明した類のアナフォリックマクロを定義するマクロだ．
\subsection{省略}   %{{{
マクロの用途の一番単純なものは，省略形として使うものだ．
Common Lispのオペレータにはかなり長い名前のものがある．
その中で高い順位を誇るものが（最長とはとても言えないが）
\verb|destructuring-bind|で，18文字になる．
Steeleの原則（sjlページ）から導かれる「系」は，
よく使われるオペレータの名前は短くあるべきということだ．
(「加算操作をコストの低いものと思う理由の一つは，
それを1文字``\,\verb|+|\,''で表記できることだ．」)
組み込みマクロ\verb|destructuring-bind|は新たな抽象化の層をもたらすが，
簡潔さの面では実際の利益はその長い名前に覆い隠されてしまう．
\begin{verbatim}
(let ((a (car x)) (b (cdr x))) ...)

(destructuring-bind (a . b) x ...)
\end{verbatim}
プログラムは，印刷された文章と同様，1行がせいぜい70文字のときが一番読み易い．
1個の識別子がその$1/4$を占めるようなときには，始めから悪条件の下に置かれたことになる．

幸運なことに，Lispのようなプログラミング言語では，言語設計者の決定に全てを任せて生きる必要はない．
次のように定義しておけば，
\begin{verbatim}
(defmacro dbind (&rest args)
  `(destructuring-bind ,@args))
\end{verbatim}
もう2度と長い名前を使う必要はない．
更に長く，しかもよく使われる\verb|multiple-value-bind|についても同様だ．
\begin{verbatim}
(defmacro mvbind (&rest args)
  `(multiple-value-bind ,@args))
\end{verbatim}
\verb|dbind|と\verb|mvbind|の定義は，どれ程似通っているか注意して欲しい．
実際，任意の関数
\footnote{省略形は\texttt{apply}や\texttt{funcall}には渡せないが．}，
マクロや特殊式の省略形を定義するには，
この形の\,\verb|&rest|引数とコンマ・アットで十分なのだ．
作業を代わりに行ってくれるマクロが手に入るというのに，
どうして更に\verb|mvbind|の方式で定義を作り出さなければならないことがあろうか？

マクロを定義するマクロを定義するには，しばしば入れ子になった逆クォートが必要になる．
逆クォートの入れ子は理解し辛いことで悪評が高い．
よく使われる形にはいつか慣れるだろうが，
逆クォートの付いた任意の式を見て，どのように展開されるかを言えるようになるとは思うべきではない．
そうなるのはLispの欠陥ではなく，ましてや表記の欠陥でもない．
込み入った積分の数式を見て値が何か知ることができないのと同じことだ．
困難は問題の中にあり，表記の中にあるのではない．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro abbrev (short long)
  `(defmacro ,short (&rest args)
     `(,',long ,@args)))

(defmacro abbrevs (&rest names)
  `(progn
     ,@(mapcar #'(lambda (pair)
                    `(abbrev ,@pair))
                (group names 2))))
\end{FramedVerb}\end{center}
\caption{省略形の自動定義．}
\label{fig:AutomaticDefOfAbbrev}
\end{figure}

しかし積分に取り組むときと同様，逆クォートの分析を小さな段階に分け，
それぞれは容易に構成を追えるようにすることはできる．
ここでマクロ\verb|abbrev|を書きたいとしよう．
これは\verb|mvbind|をただ次のようにするだけで定義できるようにしてくれるものだ．
\begin{verbatim}
(abbrev mvbind multiple-value-bind)
\end{verbatim}
第\ref{fig:AutomaticDefOfAbbrev}図には，このマクロの定義を示した．
この定義は何から出てきたのだろうか？
このようなマクロの定義は，展開例から導ける．
展開例は次のようになる．
\begin{verbatim}
(defmacro mvbind (&rest args)
  `(multiple-value-bind ,@args))
\end{verbatim}
逆クォートの中から\verb|multiple-value-bind|を取り出すと，導出は簡単になる．
最終的に作られるマクロではそれが引数になることが分かっているからだ．
こうして，次の等価な定義が得られる．
\begin{verbatim}
(defmacro mvbind (&rest args)
  (let ((name 'multiple-value-bind))
    `(,name ,@args)))
\end{verbatim}
これでこの式をテンプレートにすることができる．
先頭に逆クォートを付け，変化し得る式を変数に置き換える．
\begin{verbatim}
`(defmacro ,short (&rest args)
   (let ((name ',long))
     `(,name ,@args)))
\end{verbatim}
最後に，内側の逆クォート内の\verb|',long|を\verb|name|に置き換えて式を簡略化する．
\begin{verbatim}
`(defmacro ,short (&rest args)
   `(,',long ,@args))
\end{verbatim}
これで第\ref{fig:AutomaticDefOfAbbrev}図に示したマクロの本体が得られる．

第\ref{fig:AutomaticDefOfAbbrev}図には\verb|abbrevs|も示した．
これは複数の省略形を同時に定義したいときに使う．
\begin{verbatim}
(abbrevs dbind  destructuring-bind
         mvbind multiple-value-bind
         mvsetq multiple-value-setq)
\end{verbatim}
\verb|abbrevs|を使うには余計な括弧を挿入する必要はない．
\verb|abbrevs|は\verb|group|（aqhページ）を呼び，引数を2個ごとにまとめるからだ．
一般に，論理的には不要な括弧を打ち込むのをマクロが省いてくれるのはよいことだ．
\verb|group|はそういったマクロの大部分に役立つ．
%}}}
\subsection{属性}   %{{{
Lispは，何かの属性をオブジェクトに関連づける方法を数多く提供する．
問題とされるオブジェクトがシンボルとして表現されるときは，
一番便利な方法は（一番効率が悪いが）シンボルの属性リストを使うものだ．
オブジェクト\verb|o|が属性\verb|p|を持ち，その値が\verb|v|であるという事実を表現するには，
\verb|o|の属性リストを設定する．
\begin{verbatim}
(setf (get op) v)
\end{verbatim}
だから\verb|ball1|が色\verb|red|を持つことを表現するには，こうすればよい．
\begin{verbatim}
(setf (get 'ball1 'color) 'red)
\end{verbatim}
オブジェクトの属性のうち頻繁に参照するものがあるときは，それを参照するマクロを定義し，
\begin{verbatim}
(defmacro color (obj)
   `(get ,obj 'color))
\end{verbatim}
そして\verb|get|の場所に\verb|color|を使う．
\begin{verbatim}
> (color 'ball1)
RED
\end{verbatim}
マクロ呼び出しは\verb|setf|に対して透明なので（第12章を参照）こうも書ける．
\begin{verbatim}
> (setf (color 'ball1) 'green)
GREEN
\end{verbatim}

そのようなマクロには，
プログラムがオブジェクトの色を表現するのに使う特定の方法を隠蔽できるという利点がある．
属性リストは遅い．
プログラムの今後のヴァージョンでは，速度を考慮し，
色を構造体のフィールドまたはハッシュ表の項目として表現することになるかも知れない．
\verb|color|のように，データをそれに被せたマクロ経由で扱うと，
かなり構築の進んだプログラムにおいてすら，
最下層のコードに大きな変更を加えることが容易になる．
プログラムで使うものが属性リストから構造体に移行しても，
そこに被せたアクセス用マクロより上の段階に変更を加える必要はない．
被せたマクロを利用するコードでは，内部で起こった再構築を意識する必要すらない．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro propmacro (propname)
  `(defmacro ,propname (obj)
     `(get ,obj ',',propname)))

(defmacro propmacros (&rest props)
  `(progn
     ,@(mapcar #'(lambda (p) `(propmacro ,p))
                props)))
\end{FramedVerb}\end{center}
\caption{アクセス用マクロの自動定義．}
\label{fig:AutoDefAccessMacro}
\end{figure}

重さという属性に対しては，色に対して書いたものと似たマクロを定義すればよい．
\begin{verbatim}
(defmacro weight (obj)
  `(get ,obj 'weight))
\end{verbatim}
前節の省略形と同様に，マクロ\verb|color|と\verb|weight|の定義はほぼ同一だ．
ここで\verb|propmacro|（第\ref{fig:AutoDefAccessMacro}図）は\verb|abbrev|と同じ役割を担う．

マクロを定義するマクロを構成する過程には他のどのマクロとも違いはない．
マクロ呼び出しを，次に展開されて欲しい式を見て，
そして前者を後者に変形する方法を理解することだ．
次のマクロは，
\begin{verbatim}
(propmacro color)
\end{verbatim}
次のように展開されて欲しい．
\begin{verbatim}
(defmacro color (obj)
  `(get ,obj 'color))
\end{verbatim}
この展開形そのものにも\verb|defmacro|が使われているが，
テンプレートの作り方はやはり次の通りだ．
展開形に逆クォートを付け，\verb|color|が使われている所にコンマを付けた仮引数名を置く．
前節と同様，既存の逆クォートの中に\verb|color|が現れないように展開形を変形することから始める．
\begin{verbatim}
(defmacro color (obj)
  (let ((p 'color))
    `(get ,obj ',p)))
\end{verbatim}
そうしたら更に手順を進めてテンプレートを作り，
\begin{verbatim}
`(defmacro ,propname (obj)
   (let ((p ',propname))
     `(get ,obj ',p)))
\end{verbatim}
これを簡略化して次を得る．
\begin{verbatim}
`(defmacro ,propname (obj)
   `(get ,obj ',',propname))
\end{verbatim}

一群の属性名が全てマクロとして定義されなければならない場合のために，
\verb|propmacros| (\ref{fig:AutoDefAccessMacro}) がある．
これは複数個の\verb|propmacro|を個別に呼び出すコードに展開される．
\verb|abbrevs|と同様，実際にコードの大部分はマクロを定義するマクロを定義するマクロだ．

この節では属性リストを扱ったが，ここで扱った技法は一般的なものだ．
これを使って，どのような形で保持されているデータに対してもアクセス用マクロを定義できる．
%}}}
\subsection{アナフォリックマクロ}   %{{{
第14.1節では幾つかのアナフォリックマクロの定義を示した．
\verb|aif|や\verb|aand|のようなマクロを使うときは，
何らかの引数の評価中にはシンボル\verb|it|が他のシンボルの返した値に束縛される．
よってこうする代わりに，
\begin{verbatim}
(let ((res (complicated-query)))
  (if res
      (foo res)))
\end{verbatim}
ただこうすればよく，
\begin{verbatim}
(aif (complicated-query)
         (foo it))
\end{verbatim}
またこうする代わりに，
\begin{verbatim}
(let ((o (owner x)))
  (and o (let ((a (address o)))
           (and a (city a)))))
\end{verbatim}
ただこうすればよい．
\begin{verbatim}
(aand (owner x) (address it) (city it))
\end{verbatim}
第14.1節では7個のアナフォリックマクロを定義した．
\verb|aif|，\verb|awhen|，\verb|awhile|，\verb|acond|，\verb|alambda|，
\verb|ablock|そして\verb|aand|だ．
この種のアナフォリックマクロのうち，便利なものはこれら7個だけなどということはない．
実際，Common Lispのあらゆる関数やマクロについてアナフォリック版を定義できる．
これらのマクロの多くは\verb|mapcon|のようになるだろう．
つまり滅多に使われないが，必要なときには欠かせないようなものだ．

例えば\verb|aand|と同様に，
\verb|it|が常に前の引数の返した値に束縛されるような\verb|a+|というものを定義できる．
次の関数はマサチューセッツで食事を取るときの費用を計算する．
\begin{verbatim}
(defun mass-cost (menu-price)
  (a+ menu-price (* it .05) (* it 3)))
\end{verbatim}
マサチューセッツ食料税が5\%，また住民はしばしば税の3倍をチップとして払う．
この法則に従うと，Dolphin Seafoodでbroiled scrodを食べるときの費用はこうなる．
\begin{verbatim}
> (mass-cost 7-95)
9-54
\end{verbatim}
しかしこれはsaladとbaked potatoも含んでいる．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro a+ (&rest args)
  (a+expand args nil))

(defun a+expand (args syms)
  (if args
      (let ((sym (gensym)))
        `(let* ((,sym ,(car args))
                (it ,sym))
           ,(a+expand (cdr args)
                      (append syms (list sym)))))
      `(+ ,@syms)))

(defmacro alist (&rest args)
  (alist-expand args nil))

(defun alist-expand (args syms)
  (if args
      (let ((sym (gensym)))
        `(let* ((,sym ,(car args))
                (it ,sym))
           ,(alist-expand (cdr args)
                          (append syms (list sym)))))
      `(list ,@syms)))
\end{FramedVerb}\end{center}
\caption{\texttt{a+}と\texttt{alist}の定義．}
\label{fig:DefAPlusAlist}
\end{figure}

第\ref{fig:DefAPlusAlist}に示したマクロ\verb|a+|は，
展開形の生成を再帰関数\verb|a+expand|に依存している．
\verb|a+expand|の戦略を大雑把に言うと，
マクロ呼び出しの引数から成るリストのcdr部に対して再帰的に働き，
一連の入れ子になったlet式を生成することだ．
個々の\verb|let|は\verb|it|を異なる引数に束縛したままにするが，
個別のgensymをそれぞれの引数に束縛する．
展開関数はそれらのgensymをリストにまとめ，
引数のリストの終端に達すると，gensymを引数にした\verb|+|式を返す．
よって次の式は，
\begin{verbatim}
(a+ menu-price (* it .05) (* it 3))
\end{verbatim}
次の展開形を生成する．
\begin{verbatim}
(let* ((#:g2 menu-price) (it #:g2))
  (let* ((#:g3 (* it 0-05)) (it #:g3))
        (let* ((#:g4 (* it 3)) (it #:g4))
           (+ #:g2 #:g3 #:g4))))
\end{verbatim}

第\ref{fig:DefAPlusAlist}図には，これと似た\verb|alist|も示した．
\begin{verbatim}
> (alist 1 (+ 2 it) (+ 2 it))
(1 3 5)
\end{verbatim}

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro defanaph (name &optional calls)
  (let ((calls (or calls (pop-symbol name))))
    `(defmacro ,name (&rest args)
       (anaphex args (list ',calls)))))

(defun anaphex (args expr)
  (if args
      (let ((sym (gensym)))
        `(let* ((,sym ,(car args))
                (it ,sym))
           ,(anaphex (cdr args)
                     (append expr (list sym)))))
      expr))

(defun pop-symbol (sym)
  (intern (subseq (symbol-name sym) 1)))
\end{FramedVerb}\end{center}
\caption{アナフォリックマクロの自動定義．}
\label{fig:AutoDefOfAnaphMac}
\end{figure}

繰り返すが，\verb|a+|と\verb|alist|の定義はほぼ同一だ．
そのようなマクロをもっと定義したいようなときは，それらのほとんどがコードの重複になるだろう．
プログラムにそれらを生成させればよいではないか？
第\ref{fig:AutoDefOfAnaphMac}図のマクロ\verb|defanaph|がそれを行ってくれる．
\verb|defanaph|を使うと，\verb|a+|と\verb|alist|の定義は次のように簡潔になる．
\begin{verbatim}
(defanaph a+)
(defanaph alist)
\end{verbatim}

こうして定義された\verb|a+|と\verb|alist|の展開形は，
第\ref{fig:DefAPlusAlist}図のコードによる定義と同一だ．
マクロを定義するマクロ\verb|defanaph|は，
引数が関数と同じ通常の評価法則にしたがって評価されるものならば何であってもアナフォリック版を作れる．
すなわち，\verb|defanaph|の対象は，引数が全て評価され，かつ左から右に評価されるものならば何でもよい．
だから上に示した\verb|defanaph|では\verb|aif|や\verb|awhile|は定義できないが，
どのような関数のアナフォリック版でも定義できる．

\verb|a+|が\verb|a+expand|を呼んで展開形を生成していたのと同様，
\verb|defanaph|は\verb|anaphex|を呼んで展開形を生成する．
汎用の展開関数\verb|anaphex|が\verb|a+expand|と違っているのは，
最終的に展開形内に現れる関数名を引数に取る点だけだ．
実際，\verb|a+|は次のように定義できる．
\begin{verbatim}
(defmacro a+ (&rest args)
  (anaphex args '(+)))
\end{verbatim}
\verb|anaphex|と\verb|a+expand|のいずれも独立した関数として定義する必要はない．
\verb|anaphex|は\verb|labels|や\verb|alambda|によって\verb|defanaph|内部で定義できる．
展開形を生成する関数が上で分離されていたのは，コードを明確にするためだけだ．

普通，\verb|defanaph|は引数の先頭1文字（おそらく\verb|a|）を取り除いたものが
展開形内で呼び出されるようにする．
（これは\verb|pop-symbol|によって行われる．）
ユーザが代わりを指定したいときは，オプショナル引数で指定できる．
\verb|defanaph|は全ての関数と幾つかのマクロのアナフォリック版を定義できるが，面倒な制限が伴う．
\begin{enumerate}
    \item 引数が全て評価されるオペレータにしか適用できない．
    \item 展開形内では，\verb|it|は常に1個前の引数に束縛される．
        しかし場合によっては\wadash 例えば\verb|awhen|\wadash
        \verb|it|は第1引数の値に束縛されたままであって欲しい．
    \item \verb|setf|のように，第1引数に汎変数を取るマクロには適用できない．
\end{enumerate}
これらの制限を幾つか取り除く方法を考えよう．
第1の問題の一部は，第2の問題に帰着される．
\verb|aif|のようなマクロを定義する展開形を生成するには，
\verb|anaphex|がマクロ呼び出しの第1引数のみを置換するように修正する必要がある．
\begin{verbatim}
(defun anaphex2 (op args)
  `(let ((it ,(car args)))
     (,op it ,@(cdr args))))
\end{verbatim}
上の再帰的でない\verb|anaphex|は，
\verb|it|がマクロ展開によって一連の引数に必ず束縛されるようにする必要がないので，
マクロ呼び出しの引数を必ずしも全て評価しないような展開形を生成できる．
評価する必要があるのは第1引数だけだ
（これは\verb|it|をその値に束縛するため）．
よって\verb|aif|は次のように定義できる．
\begin{verbatim}
(defmacro aif (&rest args)
  (anaphex2 'if args))
\end{verbatim}
xqgページの元の定義との違いは，こちらでは\verb|aif|に誤った数の引数を与えるとエラーになる点だけだ．
正しいマクロ呼び出しでは，どちらも同一の展開形を生成する．

\verb|defanaph|が汎変数に対して動作しないという3番目の問題は，
展開形内で\verb|f|（gvxページ）を使うと解決できる．
\verb|setf|などのオペレータは，\verb|anaphex2|を次のように定義し直したものなら扱える．
\begin{verbatim}
(defun anaphex3 (op args)
  `(_f (lambda (it) (,op it ,@(cdr args))) ,(car args)))
\end{verbatim}
この展開関数はマクロ呼び出しが1個以上の引数を持つものと仮定している
（第1引数を汎変数にする）．
これを使うと，\verb|asetf|は次のように定義できる．
\begin{verbatim}
(defmacro asetf (&rest args)
       (anaphex3 'setf args))
\end{verbatim}

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro defanaph (name &optional &key calls (rule :all))
  (let* ((opname (or calls (pop-symbol name)))
         (body (case rule
                 (:all   `(anaphex1 args '(,opname)))
                 (:first `(anaphex2 ',opname args))
                 (:place `(anaphex3 ',opname args)))))
    `(defmacro ,name (&rest args)
       ,body)))

(defun anaphex1 (args call)
  (if args
      (let ((sym (gensym)))
        `(let* ((,sym ,(car args))
                (it ,sym))
           ,(anaphex1 (cdr args)
                      (append call (list sym)))))
      call))

(defun anaphex2 (op args)
  `(let ((it ,(car args))) (,op it ,@(cdr args))))

(defun anaphex3 (op args)
  `(_f (lambda (it) (,op it ,@(cdr args))) ,(car args)))
\end{FramedVerb}\end{center}
\caption{更に一般的な\texttt{defanaph}．}
\label{fig:MoreGeneralDefanaph}
\end{figure}

第\ref{fig:MoreGeneralDefanaph}図には，3種類の展開関数を示したが，
それらは単一のマクロである新版\verb|defanaph|によって統合されている．
プログラマはマクロ展開の望みの方式を，オプショナルなキーワード引数\verb|rule|で指定する．
すなわち，それによってマクロ呼び出しの引数を評価する際の規則を指定する．
それぞれの方式は次の通り．
\begin{description}
    \item[:all] （デフォルト）マクロ展開は\verb|alist|用の方式を取る．
        マクロ呼び出しの引数は全て評価され，\verb|it|は常に直前の引数の値に束縛される．
    \item[:first] マクロ展開は\verb|aif|用の方式を取る．
        必ず評価されるのは第1引数のみで，\verb|it|はその値に束縛される．
    \item[:place] マクロ展開は\verb|asetf|用の方式を取る．
        第1引数は汎変数として扱われ，\verb|it|はその初期値に束縛される．
\end{description}
新しい\verb|defanaph|を使うと，ここまでに示した例の幾つかは次のように定義できる．
\begin{verbatim}
(defanaph alist)
(defanaph aif :rule :first)
(defanaph asetf :rule :place)
\end{verbatim}

\verb|asetf|には，汎変数を使う多種多様なマクロを複数回の評価について心配せずに定義できる長所がある．
例えば，\verb|incf|は次のように定義できる．
\begin{verbatim}
(defmacro incf (place &optional (val 1))
  `(asetf ,place (+ it ,val)))
\end{verbatim}
また，例えば\verb|pull|（sqkページ）は次のように定義できる．
\begin{verbatim}
(defmacro pull (obj place &rest args)
  `(asetf ,place (delete ,obj it ,@args)))
\end{verbatim}
%}}}
%}}}
\section{リードマクロ} %{{{
LispのS式の生涯で重要な瞬間は3つ，すなわち読み込み時，コンパイル時，実行時だ．
関数を操れるのは実行時だ．
マクロによりプログラムをコンパイル時に変換する機会が得られる．
この章ではリードマクロを扱うが，これは読み込み時に機能するものだ．
\subsection{マクロ文字}   %{{{
Lispの基本的思想に従い，リーダは大幅に制御することができる．
リーダの動作は完全に実行中の変更が効く属性値と変数で制御できる．
リーダは複数の段階でプログラムできる．
一番容易に動作を変更する方法は，新しいマクロ文字を定義することだ．

マクロ文字とはLispのリーダから特別な扱いを要求する文字だ．
例えば小文字の\verb|a|は普通は小文字の\verb|b|と全く同じ扱いだが，開き括弧は少々異なる．
開き括弧はリストの読み込みが開始したことの印だ．
そういった文字にはそれぞれ関数が関連付けられており，
それがLispのリーダにその文字を読み込んだ際の指示を与える．
既存のマクロ文字に関連付けられた関数を変更することもできるし，
独自のマクロ文字を定義することもできる．

組み込み関数\verb|set-macro-character|を使うのがリードマクロを定義する方法の1つだ．
これは引数に1個の文字と1個の関数を取るが，
その後\verb|read|がその文字を読み込んだら，\verb|read|はその関数を呼んだ結果を返すようになる．

\begin{figure}\begin{center}\begin{FramedVerb}
(set-macro-character #\'
  #'(lambda (stream char)
      (list 'quote (read stream t nil t))))
\end{FramedVerb}\end{center}
\caption{\texttt{'}はこのようにも定義できる.}
\label{fig:PossibleDefQuote}
\end{figure}

Lispで最古参のリードマクロの1つは\,\verb|'|\,すなわちクォートだ．
\verb|'|がなくとも，常に\,\verb|'a|の代わりに\verb|(quote a)|とすることもできる．
しかしそれは面倒だし，コードも読み辛くなってしまうだろう．
読み込みマクロ\verb|quote|のおかげで\,\verb|'a|を\verb|(quote a)|の代わりに使える．
それは第\ref{fig:PossibleDefQuote}図のように定義することもできる．

\verb|read|は通常のコンテキスト
（例えば\,\verb|"a'b"|\,や\,\verb@|a'b|@\,は除く）で\,\verb|'|\,を読み込むと，
現在のストリームと文字についてこの関数を呼んだ結果を返す．
（この関数は第2引数を無視する．どうせ必ずクォート文字だからだ．）
よって\verb|read|は\,\verb|'a|を読むと\verb|(quote a)|を返す．

\verb|read|の引数の最後の3個はそれぞれ以下のことを制御する．
すなわち，ファイル終端に達したときにエラーを起こすべきか，起こさないなら何の値を返すか，
\verb|read|を呼び出している間にも\verb|read|が呼び出されるかどうか．
ほとんど全てのリードマクロで第2と第4引数は\verb|t|であるべきで，
またその帰結として第3引数はどうでもよい．

リードマクロと普通のマクロには，共に関数が背後にある．
そしてマクロの展開形を生成する関数と同様に，マクロ文字に関連付けられた関数は，
読み込み元のストリームに対して以外は副作用を持つべきでない．
リードマクロに関連付けられた関数がいつ，またはどれ程頻繁に呼ばれるかについて，
Common Lispは一切の保証を明示していない．
（\textsf{CLtL2}の543ページを参照）

マクロとリードマクロは，コードをそれぞれ異なった段階で受け取る．
マクロはコードがリーダによって既にLispのオブジェクトへとパースされた時点で受け取るが，
リードマクロはコードがまだテキストである間にそれに作用する．
しかしこのテキストに対し\verb|read|を呼ぶことで，
リードマクロも（望みとあらば）同様にパース済みのLispオブジェクトを得ることができる．
だからリードマクロは少なくとも普通のマクロと同程度の力を持っている．

実際には，リードマクロの方が少なくとも2点でマクロより強力だ．
リードマクロはLispの読み込むもの全てに影響できるが，マクロはコード内に展開されるだけだ．
またリードマクロは一般に\verb|read|を再帰的に呼ぶので，次のような式は，
\begin{verbatim}
''a
\end{verbatim}
次のように展開される．
\begin{verbatim}
(quote (quote a))
\end{verbatim}
しかし\verb|quote|の省略形を普通のマクロで定義しようとすると，
それは孤立した状態では機能するが，
\begin{verbatim}
> (eq 'a (q a))
T
\end{verbatim}
入れ子になると機能しない．
例えば，
\begin{verbatim}
(q (q a))
\end{verbatim}
としても次のようにしかならない．
\begin{verbatim}
(quote (q a))
\end{verbatim}
%}}}
\subsection{マクロ文字のディスパッチング}   %{{{
シャープクォートは，\verb|#|\,で始まる他のリードマクロと同様，
ディスパッチング・リードマクロと呼ばれる亜種の例だ．
それらは2文字で使われるが，その1文字目はディスパッチング文字と呼ばれる．
そのようなリードマクロの目的は，単にASCII文字集合を最大限に活用することだけだ．
1文字のリードマクロはせいぜいASCII文字集合の数だけしか定義できない．

（\verb|make-dispatch-macro-character|によって）独自のディスパッチング・マクロ文字が定義できるが，
\verb|#|\,が既にそれとして定義されているので，それを使ってもよい．
\verb|#|\,で始まる組合せの幾つかは独自利用のために明示的に予約されている．
他の組合せは，Common Lispで予め定義された意味を持たない限り利用できる．
網羅的な一覧は\textsf{CLtL2}の531ページにある．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro q (obj)
  `(quote ,obj))
     (set-dispatch-macro-character #\# #\?
       #'(lambda (stream char1 char2)
            `#'(lambda (&rest ,(gensym))
                  ,(read stream t nil t))))
\end{FramedVerb}\end{center}
\caption{定数関数のためのリードマクロ．}
\label{fig:ReadMacroForConstFunc}
\end{figure}

ディスパッチングマクロ文字の新たな組合せは，関数\verb|set-dispatch-macro-character|で定義できる．
これは\verb|set-macro-character|と似ているが，文字の引数を2個取る点が異なる．
プログラマに予約されている組合せの一つは\,\verb|#?|\,だ．
第\ref{fig:ReadMacroForConstFunc}図には，
この組合せを定数関数のためのリードマクロとして定義する方法を示した．
それによると\,\verb|#?2|\,は任意個数の引数を取って2を返す関数として読み込まれる．
例:
\begin{verbatim}
> (mapcar #?2 '(a b c))
(2 2 2)
\end{verbatim}
この例では新オペレータはかなり無意味に見えるが，
関数を引数に使うことがひどく多いプログラムでは，定数関数もしばしば必要になる．
事実，Lispの方言によっては定数関数を定義するための\verb|always|という組込み関数が用意されている．

マクロ文字をそのマクロ文字の定義内に使うことは全く問題ないことに注意しよう．
他のどのLisp式とも同じように，それらは定義が読み込まれたときに消えてしまう．
マクロ文字は\,\verb|#?|\,の後に使っても構わない．
\verb|#?|\,の定義では\verb|read|を呼んでいるので，
\verb|'|や\,\verb|#'|等のマクロ文字は普通通りに機能する．
\begin{verbatim}
> (eq (funcall #?'a) 'a)
T
> (eq (funcall #?#'oddp) (symbol-function 'oddp))
T
\end{verbatim}
%}}}
\subsection{デリミタ}   %{{{
\begin{figure}\begin{center}\begin{FramedVerb}
(set-macro-character #\] (get-macro-character #\)))

(set-dispatch-macro-character #\# #\[
  #'(lambda (stream char1 char2)
      (let ((accum nil)
            (pair (read-delimited-list #\] stream t)))
        (do ((i (ceiling (car pair)) (1+ i)))
          ((> i (floor (cadr pair)))
           (list 'quote (nreverse accum)))
          (push i accum)))))
\end{FramedVerb}\end{center}
\caption{リードマクロを定義するデリミタ．}
\label{fig:ReadMacroDefngDlmt}
\end{figure}

単純なマクロ文字の次によく使われるマクロ文字は，リストのデリミタだ．
ユーザに予約されている組合せには\,\verb|#[|もある．
第\ref{fig:ReadMacroDefngDlmt}図には，
それを手の込んだ仕組みを持つ開き括弧の一種として定義する方法を示した．
そこでは\,\verb|#[x y]|という形の式を
\verb|x|以上\verb|y|以下の整数全てから成るリストとして読み込ませるようにしている．
\begin{verbatim}
> #[2 7]
(2 3 4 5 6 7)
\end{verbatim}
このリードマクロで新しいのは\verb|read-delimited-list|を呼んでいる点だけだ．
これはちょうどこのような場合のために用意された組込み関数だ．
第1引数にはリストの終わりとして扱う文字を与える．
\verb|]|が\,\verb|#[|を閉じるデリミタとして認識されるためには，
先にデリミタの一種に含まれていなければならないので，予め\verb|set-macro-character|を呼ぶ必要がある．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro defdelim (left right parms &body body)
  `(ddfn ,left ,right #'(lambda ,parms ,@body)))

(let ((rpar (get-macro-character #\) )))
  (defun ddfn (left right fn)
    (set-macro-character right rpar)
    (set-dispatch-macro-character #\# left
       #'(lambda (stream char1 char2)
           (apply fn
                  (read-delimited-list right stream t))))))
\end{FramedVerb}\end{center}
\caption{デリミタ・リードマクロを定義するためのマクロ．}
\label{fig:MacroForDefngDlmtReadMacro}
\end{figure}

デリミタ・リードマクロの定義ではほぼ毎回第\ref{fig:ReadMacroDefngDlmt}図のコードの多くが
繰り返し使われるだろう．
マクロならそれを行う仕組みに抽象化されたインタフェイスを備えさせることができる．
第\ref{fig:MacroForDefngDlmtReadMacro}図には，
デリミタ・リードマクロを定義するためのユーティリティの定義例を示した．
マクロ\verb|defdelim|は引数に2個の文字，仮引数リスト及び本体になるコードを取る．
引数リストと本体コードは暗黙のうちに関数を定義する．
\verb|defdelim|を呼び出すと，1文字目をディスパッチング・リードマクロとして，
2文字目をその終端として定義する．
そして定義された関数をそれらの間のものに適用した結果を返すようにする．
ついでに言えば，第\ref{fig:ReadMacroDefngDlmt}図の関数本体もユーティリティを欲しがっている．
すなわち，既に定義した\verb|mapa-b|（ckvページ）だ．
\verb|defdelim|と\verb|mapa-b|を使うと，
第\ref{fig:ReadMacroDefngDlmt}図で定義したリードマクロは次のように書ける．
\begin{verbatim}
(defdelim #\[ #\] (x y)
  (list 'quote (mapa-b #'identity (ceiling x) (floor y))))
\end{verbatim}

デリミタ・リードマクロは関数の合成にも使うと便利だ．
第5.4節では関数合成用のオペレータを定義した．
\begin{verbatim}
> (let ((f1 (compose #'list #'1+))
        (f2 #'(lambda (x) (list (1+ x)))))
    (equal (funcall f1 7) (funcall f2 7)))
T
\end{verbatim}
組込み関数の\verb|list|と\verb|1+|等を合成するときには，
\verb|compose|の呼び出しの評価を実行時まで待つ理由はない．
第5.7節では代替方法を紹介した．
リードマクロのシャープドットを\verb|compose|式の頭に付けることで，それを読み込み時に評価できる．

\begin{figure}\begin{center}\begin{FramedVerb}
#.(compose #'list #'1+)
(defdelim #\@{ #\@} (&rest args)
          `(fn (compose ,@args)))
\end{FramedVerb}\end{center}
\caption{関数合成のためのリードマクロ．}
\label{fig:ReadMacroForFuncComp}
\end{figure}

ここでは似ているがさらにきれいな解決法を示そう．
第\ref{fig:ReadMacroForFuncComp}図のリードマクロは，\verb|#@{f 1 f 2 ...fn@}|という形の式が
\verb|f1|，\verb|f2|，\ldots，\verb|fn|を合成したものとして読み込まれるように定義する．
よってこうなる．
\begin{verbatim}
> (funcall #@{list 1+@} 7)
(8)
\end{verbatim}
これは\verb|fn|（gfdページ）の呼び出しを生成することで動作する．
\verb|fn|はコンパイル時に関数を生成できるものだ．
%}}}
\subsection{いつ何が起きるのか}   %{{{
最後に，混乱するかもしれない点についてはっきりさせておいた方がよいかもしれない．
リードマクロが普通のマクロより先に呼び出されるなら，
マクロがリードマクロを含む式に展開されるというのは何なのだろうか？
例えば次のマクロは，
\begin{verbatim}
(defmacro quotable ()
  '(list 'able))
\end{verbatim}
クォートを含む式に展開される．
さてそれは本当だろうか？
実は，このマクロの定義内にあるどちらのクォートも\verb|defmacro|式が読み込まれたときに展開され，
次のようになる．
\begin{verbatim}
(defmacro quotable ()
  (quote (list (quote able))))
\end{verbatim}
普通はマクロの展開形にリードマクロが含まれると思っていても不都合はないが，
それはリードマクロの定義は読み込み時とコンパイル時で変わらないはず（変わるべきでない）からだ．
%}}}
%}}}
\section{構造化代入} %{{{
構造化代入とは，代入の一般化だ．
オペレータ\verb|setq|と\verb|setf|は個々の変数に代入を行う．
構造化代入は代入をアクセスと組み合わせる．
第1引数に変数を単独で置くのではなく，変数のパターンを与える．
すると各々に同じ構造の対応する場所に置かれた値が代入される．
\subsection{リストに対する構造化代入}   %{{{
\textsf{CLtL2}では，Common Lispに新マクロ\verb|destructuring-bind|が加わった．
このマクロは第7章で簡単に扱ったが，ここでは詳しく検討する．
\verb|lst|が要素を3つ持つリストで，\verb|x|に第1要素を，\verb|y|に第2，
\verb|z|に第3要素を束縛したいとしよう．
\textsf{CLtL1}のみに対応のCommon Lispでは，こうしなければならない．
\begin{verbatim}
(let ((x (first lst))
      (y (second lst))
      (z (third lst)))
...)
\end{verbatim}
新マクロを使うと，代わりにこう書くことができる．
\begin{verbatim}
(destructuring-bind (x y z) lst
  ...)
\end{verbatim}
これは短いだけでなく，形も整っている．
ものを読むときには視覚的手がかりは文字上のものより遥かに速く認識される．
後の形では\verb|x|，\verb|y|と\verb|z|の関係が示されているが，
前の形では推論が必要になる．

このように単純な場合すら構造化代入によってきれいにできるのだから，
複雑な場合にどれほど読みやすくなるか想像して欲しい．
\verb|destructuring-bind|の第1引数には任意の複雑なツリーを渡せる．
次のコードが，\verb|let|とリストへのアクセス関数を使って書かれたらどうなるか想像して欲しい．
\begin{verbatim}
(destructuring-bind ((first last) (month day year) . notes)
                     birthday
  ...)
\end{verbatim}
これから新しく分かることがある．
構造化代入は，プログラムを読み易くするだけでなく書き易くもする．

構造化代入は\textsf{CLtL1}のCommon Lispにも確かに存在した．
上述の例が見慣れたものに思えるなら，それはマクロの仮引数リストと同じ形式を持っているからだ．
実際，\verb|destructuring-bind|はマクロの引数リストを分離するために使われるコードだが，
今ではそれが独立したオペレータになったのだ．
マクロの仮引数リストに入れられるものなら何でもパターンに入れられる．
（ただし些細な例外がある．キーワード\verb|&environment|だ．）

束縛をいちどきに生成するのは魅力的な発想だ．
以下の節ではこの考えの変化形を幾つか説明する．
%}}}
\subsection{他の構造}   %{{{
構造化代入をリストに限る理由はなく，複雑なオブジェクトはどれもその候補になる．
この節では，リスト以外のオブジェクト用の\verb|destructuring-bind|類似マクロの書き方を説明する．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro dbind (pat seq &body body)
  (let ((gseq (gensym)))
    `(let ((,gseq ,seq))
       ,(dbind-ex (destruc pat gseq #'atom) body))))

(defun destruc (pat seq &optional (atom? #'atom) (n 0))
  (if (null pat)
      nil
      (let ((rest (cond ((funcall atom? pat) pat)
                        ((eq (car pat) '&rest) (cadr pat))
                        ((eq (car pat) '&body) (cadr pat))
                        (t nil))))
        (if rest
            `((,rest (subseq ,seq ,n)))
            (let ((p (car pat))
                  (rec (destruc (cdr pat) seq atom? (1+ n))))
              (if (funcall atom? p)
                  (cons `(,p (elt ,seq ,n))
                        rec)
                  (let ((var (gensym)))
                    (cons (cons `(,var (elt ,seq ,n))
                                (destruc p var atom?))
                          rec))))))))

(defun dbind-ex (binds body)
  (if (null binds)
      `(progn ,@body)
      `(let ,(mapcar #'(lambda (b)
                         (if (consp (car b))
                             (car b)
                             b))
                     binds)
         ,(dbind-ex (mapcan #'(lambda (b)
                                (if (consp (car b))
                                    (cdr b)))
                            binds)
                    body))))
\end{FramedVerb}\end{center}
\caption{シークェンス一般に構造化代入を行うオペレータ．}
\label{fig:GeneralSeqDestructuringOp}
\end{figure}

次の自然な一歩は，シークェンス一般を扱うことだ．
第\ref{fig:GeneralSeqDestructuringOp}図には\verb|dbind|というマクロを示した．
これは\verb|destructuring-bind|と似ているが，任意の種類のシークェンスに対して機能する．
第2引数にはリスト，ヴェクタ，またはそれらの任意の組合せが使える．
\begin{verbatim}
> (dbind (a b c) #(1 2 3)
        (list a b c))
(123)
> (dbind (a (b c) d) '( 1 #(2 3) 4)
        (list a b c d))
(1234)
> (dbind (a (b . c) &rest d) '(1 "fribble" 2 3 4)
        (list a b c d))
(1 #\f "ribble" (2 3 4))
\end{verbatim}

リードマクロ\,\verb|#(|はヴェクタを表現するためのもので，\verb|#\|は文字を表現するためのものだ．
$\verb|"abc"|=\verb|#(#\a #\b #\c)|$なので，\verb|"fribble"|の第1要素は文字\verb|#\f|だ．
話を単純にするため，\verb|dbind|は\verb|&rest|及び\verb|&body|キーワードのみに対応する．

これまでに見た大半のマクロと比べて，\verb|dbind|は大きい．
このマクロの実装方法は学んでおく価値がある．
いかに動作するかが理解できるだけでなく，
そこからLispプログラミング一般に通じる教訓が得られるからだ．
第3.4節で触れたように，Lispプログラムは意図的にテストしやすいように書くことができる．
ほとんどのコードでは，そのように書きたい欲求と速度を出す必要性とのバランスを取らなければならない．
うまいことに，第7.8節で説明したように，マクロ展開コードにとって速度は重要ではない．
マクロの展開形を生成するコードを書くときには，自分自身の人生を楽にするように書いてよい．
\verb|dbind|の展開形は，2個の関数\verb|destruc|と\verb|dbind-ex|によって生成される．
恐らく全てを単一パスで行う1個の関数にこれらをまとめることもできるだろう．
しかしどうしてそんなことに拘るだろうか？
2個の別々な関数であれば，テストは簡単だ．
どうしてこの利点を，必要もない速度と交換にかけるだろうか？

1個目の関数\verb|destruc|は実行時にパターンを探索し，
各々の変数を対応するオブジェクトの位置と関連づける．
\begin{verbatim}
> (destruc '(a b c) 'seq #'atom)
((A (ELT SEQ 0)) (B (ELT SEQ 1)) (C (ELT SEQ 2)))
\end{verbatim}
第3引数はオプションの述語で，それはパターン構造とパターンの内容を区別するのに使われる．

アクセスを効率的にするため，新しい変数（gensym）が部分シークェンスそれぞれに束縛される．
\begin{verbatim}
> (destruc '(a (b . c) &rest d) 'seq)
((A (ELT SEQ 0))
 ((#:G2 (ELT SEQ 1)) (B (ELT #:G2 0)) (C (SUBSEQ #:G2 1)))
 (D (SUBSEQ SEQ 2)))
\end{verbatim}

\verb|destruc|の出力は\verb|dbind-ex|に送られ，マクロの膨大な展開形が生成される．
それは\verb|destruc|の生成したツリーを入れ子になった幾つかの\verb|let|に変形する．
\begin{verbatim}
> (dbind-ex (destruc '(a (b . c) &rest d) 'seq) '(body))
(LET ((A (ELT SEQ 0))
      (#:G4 (ELT SEQ 1))
      (D (SUBSEQ SEQ 2)))
  (LET ((B (ELT #:G4 0))
        (C (SUBSEQ #:G4 1)))
    (PROGN BODY)))
\end{verbatim}

\verb|dbind|は，\verb|destructuring-bind|と同様に，
探しているリスト構造が全て見つかるものと仮定していることに注意しよう．
対応する式のなかった変数は，\verb|multiple-value-bind|のように\verb|nil|には束縛されない．
実行時に与えられたシークェンスに予期された要素が幾つか見つからなかったときは，
構造化代入オペレータはエラーを生成する．
\begin{verbatim}
> (dbind (a b c) (list 1 2))
>>Error: 2 is not a valid index for the sequence (1 2)
\end{verbatim}

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro with-matrix (pats ar &body body)
  (let ((gar (gensym)))
    `(let ((,gar ,ar))
       (let ,(let ((row -1))
               (mapcan
                 #'(lambda (pat)
                     (incf row)
                     (setq col -1)
                     (mapcar #'(lambda (p)
                                 `(,p (aref ,gar
                                            ,row
                                            ,(incf col))))
                             pat))
                 pats))
         ,@body))))

(defmacro with-array (pat ar &body body)
  (let ((gar (gensym)))
    `(let ((,gar ,ar))
       (let ,(mapcar #'(lambda (p)
                         `(,(car p) (aref ,gar ,@(cdr p))))
                     pat)
         ,@body))))
\end{FramedVerb}\end{center}
\caption{配列に対する構造化代入．}
\label{fig:DestructuringOnArray}
\end{figure}

内部構造を持つオブジェクトは他に何があるだろうか？
一般の配列がある．
これとヴェクタとの違いは次元が1より大きいことだ．
構造化代入マクロを配列に定義するとして，パターンをどのようにひょうげんすればよいだろう？
2次元配列に対しては，やはりリストを使うのが効率的だ．
第\ref{fig:DestructuringOnArray}図にはマクロ\verb|with-matrix|を示した．
これは2次元配列に対して構造化代入を行うためのものだ．
\begin{verbatim}
> (setq ar (make-array '(3 3)))
#<Simple-Array T (3 3) C2D39E>
> (for (r 0 2)
    (for (c 0 2)
      (setf (aref ar r c) (+ (* r 10) c))))
NIL
> (with-matrix ((a b c)
                (d e f)
                (g h i)) ar
               (list a b c d e f g h i))
(0 1 2 10 11 12 20 21 22)
\end{verbatim}

大きい配列や3次元以上の配列に対しては，異なったアプローチが必要だ．
変数を大きい配列の要素それぞれに束縛したいことはまずない．
配列の疎表現を行うパターンを作る方が実用的だろう．
幾つかの要素だけに対応する変数と，要素を選ぶための座標を含む表現だ．
第\ref{fig:DestructuringOnArray}図の2個目のマクロはこの原則に基づいて作られている．
上記の例の配列の対角成分を求めるにはこのようにする．
\begin{verbatim}
> (with-array ((a 0 0) (d 1 1) (i 2 2)) ar
    (values a d i))
0 11 22
\end{verbatim}

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro with-struct ((name . fields) struct &body body)
  (let ((gs (gensym)))
    `(let ((,gs ,struct))
       (let ,(mapcar #'(lambda (f)
                         `(,f (,(symb name f) ,gs)))
                     fields)
         ,@body))))
\end{FramedVerb}\end{center}
\caption{構造体に対する構造化代入．}
\label{fig:DestructuringOnStruc}
\end{figure}

このマクロによって，要素が一定の順番で現れなければならないパターンを卒業しつつある．
変数を\verb|defstruct|で定義された構造体のフィールド（訳注: メンバとも）に束縛するための，
類似のマクロが作れる．
そのようなマクロを第\ref{fig:DestructuringOnStruc}図に示した．
パターンの第1要素は構造体名に関連付けられた一種の接頭辞として，残りはフィールド名として扱われる．
アクセス呼び出しを行うため，このマクロは\verb|symb|（lgwページ）を使っている．
\begin{verbatim}
> (defstruct visitor name title firm)
VISITOR
> (setq theo (make-visitor :name "Theodebert"
                           :title 'king
                           :firm 'franks))
#S(VISITOR NAME "Theodebert" TITLE KING FIRM FRANKS)
> (with-struct (visitor- name firm title) theo
    (list name firm title))
("Theodebert" FRANKS KING)
\end{verbatim}
%}}}
\subsection{参照}   %{{{
CLOSはインスタンスに対して構造化代入を行うマクロを提供する．
\verb|tree|が3個のスロット（訳注: クラスのインスタンス変数とも）\verb|species|，
\verb|age|と\verb|height|を持つクラスで，\verb|my-tree|が\verb|tree|のインスタンスだとしよう．
次の式の中では，
\begin{verbatim}
(with-slots (species age height) my-tree
  ...)
\end{verbatim}
\verb|my-tree|のスロットは，あたかも普通の変数であるかのように参照できる．
\verb|with-slots|の本体内では，シンボル\verb|height|はスロット\verb|height|を参照する．
そこに保持された値に束縛されたというだけでなくスロットそのものを参照するので，
次のように書くと，
\begin{verbatim}
(setq height 72)
\end{verbatim}
\verb|my-tree|のスロット\verb|height|には72という値が与えられる．
このマクロは\verb|height|をスロットの参照に展開されるシンボル・マクロ（第7.11節）として
定義することで機能している．
実際，\verb|symbol-macrolet|がCommon Lispに追加されたのは
\verb|with-slots|等のマクロを実現するためだ．

\verb|with-slots|が本当の構造化代入マクロであろうとなかろうと，
実用的には\verb|destructuring-bind|と同じ役割を持つ．
古典的な構造化代入が値渡しであるのに対し，この種のものは参照渡しだ．
それを何と呼ぶにしても，便利なのは間違いなさそうだ．
同じ原則に基づいて，どんなマクロが他に定義できるだろうか？

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro with-places (pat seq &body body)
  (let ((gseq (gensym)))
    `(let ((,gseq ,seq))
       ,(wplac-ex (destruc pat gseq #'atom) body))))

(defun wplac-ex (binds body)
  (if (null binds)
      `(progn ,@body)
      `(symbol-macrolet ,(mapcar #'(lambda (b)
                                     (if (consp (car b))
                                         (car b)
                                         b))
                                 binds)
                        ,(wplac-ex (mapcan #'(lambda (b)
                                               (if (consp (car b))
                                                   (cdr b)))
                                           binds)
                                   body))))
\end{FramedVerb}\end{center}
\caption{シークェンスに対する構造化代入の参照渡し版．}
\label{fig:RefDestructuringOnSeq}
\end{figure}
\begin{verbatim}
\end{verbatim}

任意の構造化代入マクロの参照渡し版が，
\verb|let|でなく\verb|symbol-macrolet|に展開するようにすることで定義できる．
第\ref{fig:RefDestructuringOnSeq}図には，
\verb|dbind|を\verb|with-slots|のように振る舞うように修正したものを示した．
\verb|with-places|は，\verb|dbind|を使うのと同じように使える．
\begin{verbatim}
> (with-places (a b c) #(1 2 3)
    (list a b c))
(1 2 3)
\end{verbatim}

しかしこの新マクロを使うと，\verb|with-slots|で行うのと同様に，
シークェンス内のある位置に\verb|setf|を適用することもできる．
\begin{verbatim}
> (let ((lst '(1 (2 3) 4)))
    (with-places (a (b . c) d) lst
      (setf a 'uno)
      (setf c '(tre)))
    lst)
(UNO (2 TRE) 4)
\end{verbatim}
ここでは\verb|with-slots|の場合と同様，変数は構造体の対応する場所を参照している．
しかし他にも重要な違いがある．
それらの疑似変数に値を設定するには\verb|setq|でなく\verb|setf|を使わなければならない．
マクロ\verb|with-slots|は本体内で使われた\verb|setq|を\verb|setf|に置き換えるために
\verb|code-walker|（rcxページ）を呼び出さなければならない．
ここで\verb|code-walker|を書いても，コード量の割に改善点は小さくなってしまう．

\verb|with-places|が\verb|dbind|より一般的だと言うなら，どうしてそちらを常に使わないのだろうか？
\verb|dbind|は変数を値に束縛するが，
\verb|with-places|は変数を，値を見つけるための一連の指示に関連付ける．
参照の度に検索が必要になる．
\verb|dbind|が変数\verb|c|を\verb|(elt x 2)|の値に束縛する所を，
\verb|with-places|は\verb|c|を\verb|(elt x 2)|に展開されるシンボル・マクロにする．
だから\verb|c|が本体内で$n$回評価されるときは，\verb|elt|の呼び出しを$n$回伴う．
構造化代入で作られた変数に本当に\verb|setf|を使いたいときでなければ，
\verb|dbind|の方が速いだろう．

\verb|with-places|の定義は\verb|dbind|の定義（第\ref{fig:GeneralSeqDestructuringOp}と
わずかに異なるだけだ．
\verb|wplac-ex|（\verb|dbind-ex|の改良版）の中では\verb|let|は\verb|symbol-macrolet|に変わっている．
似たような変更によって，任意の普通の構造化代入マクロの参照渡し版を作れる．
%}}}
\subsection{マッチング}   %{{{
構造化代入が代入の一般化であるのと同様，パターンマッチングは構造化代入の一般化だ．
「パターンマッチング」という言葉には幾つも意味がある．
ここでの文脈では，それは（ときには変数を含む）2つの構造を比較し，
それらを同一にするような変数への値の代入方法がないかどうか調べることだ．
例えば\verb|?x|と\verb|?y|が変数ならば，
次の2つのリストは$\verb|?x| = \verb|a|$かつ$\verb|?y| = \verb|b|$のときにマッチする．
\begin{verbatim}
   (p ?x ?y c ?x)
   (p a b c a)
\end{verbatim}
また次のリストは$\verb|?x| = \verb|?y| = \verb|c|$のときにマッチする．
\begin{verbatim}
   (p ?x b ?y a)
   (p ?y b c a)
\end{verbatim}

外部とメッセージをやりとりすることで動作するプログラムを考えよう．
メッセージに反応するには，そのメッセージがどの種類のものか判別しなければならず，
またそのメッセージの内容を抽出しなければならない．
マッチング・オペレータを使うと，2つの段階を組み合わせられる．

そのようなオペレータを書けるようにするには，変数を他から区別する方法が必要になる．
シンボルはみな変数だなどと言うことはできない．
シンボルには引数としてパターン内に現れてほしいからだ．
ここではパターン変数はクエスチョンマークで始まる変数としよう．
それで不便なことがあったら，述語\verb|var?|を再定義するだけでその決まりを変更できる．

\begin{figure}\begin{center}\begin{FramedVerb}
(defun match (x y &optional binds)
  (acond2
    ((or (eql x y) (eql x '_) (eql y '_)) (values binds t))
    ((binding x binds) (match it y binds))
    ((binding y binds) (match x it binds))
    ((varsym? x) (values (cons (cons x y) binds) t))
    ((varsym? y) (values (cons (cons y x) binds) t))
    ((and (consp x) (consp y) (match (car x) (car y) binds))
     (match (cdr x) (cdr y) it))
    (t (values nil nil))))

(defun varsym? (x)
  (and (symbolp x) (eq (char (symbol-name x) 0) #\?)))

(defun binding (x binds)
  (labels ((recbind (x binds)
                    (aif (assoc x binds)
                         (or (recbind (cdr it) binds)
                             it))))
    (let ((b (recbind x binds)))
      (values (cdr b) b))))
\end{FramedVerb}\end{center}
\caption{マッチング関数．}
\label{fig:MatchingFunc}
\end{figure}

第\ref{fig:MatchingFunc}図には，幾つかのLisp入門書に出て来るのと似たパターンマッチング関数を示した．
\verb|match|には2つのリストを与える．
それらがマッチするようにできるならば，そのマッチを実現するリストが返される．
\begin{verbatim}
> (match '(p a b c a) '(p ?x ?y c ?x))
((?Y . B) (?X . A))
T
> (match '(p ?x b ?y a) '(p ?y b c a))
((?Y . C) (?X . ?Y))
T> (match '(a b c) '(a a a))
NIL
NIL
\end{verbatim}

\verb|match|は引数を要素毎に比較しつつ，
束縛と呼ばれる，変数への値の関連付けを生成し，変数\verb|binds|の中に保持する．
\verb|match|はマッチに成功すると生成された束縛を返し，失敗すると\verb|nil|を返す．
マッチが成功しても必ずしも束縛が生成される訳ではないので，
\verb|match|は\verb|gethash|と同様に第2返り値でマッチに成功したかどうかを表す．
\begin{verbatim}
> (match '(p ?x) '(p ?x))
NIL
T
\end{verbatim}
\verb|match|が上のように\verb|nil|と\verb|t|を返したときは，
マッチに成功したが束縛は作られなかったことを示す．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro if-match (pat seq then &optional else)
  `(aif2 (match ',pat ,seq)
         (let ,(mapcar #'(lambda (v)
                           `(,v (binding ',v it)))
                       (vars-in then #'atom))
           ,then)
         ,else))

(defun vars-in (expr &optional (atom? #'atom))
  (if (funcall atom? expr)
      (if (var? expr) (list expr))
      (union (vars-in (car expr) atom?)
             (vars-in (cdr expr) atom?))))

(defun var? (x)
  (and (symbolp x) (eq (char (symbol-name x) 0) #\?)))
\end{FramedVerb}\end{center}
\caption{遅いマッチングオペレータ}
\label{fig:SlowMatchingOp}
\end{figure}

Prologと同様，\verb|match|は\,\verb|_|\,（下線）をワイルドカードとして扱う．
これは全てにマッチし，束縛には影響しない．
\begin{verbatim}
> (match '(a ?x b) '(_ 1 _))
((?X . 1))
T
\end{verbatim}

\verb|match|があれば，パターンマッチングを行う\verb|dbind|を書くのは容易だ．
第\ref{fig:SlowMatchingOp}図には\verb|if-match|というマクロを示した．
\verb|dbind|と同様，第1，第2引数はパターンとシークェンスで，
パターンをシークェンスと比較することで束縛が生成される．
しかし本体の代わりに引数がさらに2つある．
\verb|match|がマッチングに成功したとき，そこで作られた束縛の下で評価されるthen節と，
マッチングに失敗したときに評価されるelse節だ．
次に\verb|if-match|を使った簡単な関数を示す．
\begin{verbatim}
(defun abab (seq)
  (if-match (?x ?y ?x ?y) seq
            (values ?x ?y)
            nil))
\end{verbatim}
マッチに成功すると，\verb|?x|と\verb|?y|に対応する値が定められ，返り値になる．
\begin{verbatim}
> (abab '(hi ho hi ho))
HI
HO
\end{verbatim}

関数\verb|vars-in|はパターン内の全てのパターン変数を返す．
これは\verb|var?|を呼んで変数かどうかの判断を行っている．
この時点では\verb|var?|は\verb|varsym?|（第\ref{fig:MatchingFunc}図）と同一の関数だ．
これは束縛リスト内の変数を判別するのに使われる．
2つの関数を個別に用意したのは， 2種類の変数に異なった表現を使いたくなったときのためだ．

第\ref{fig:SlowMatchingOp}図を見ると，\verb|if-match|は短いが，余り効率がよくない．
処理を実行時に行い過ぎる．
第1のシークェンスがコンパイル時に分かっているときですら，
両方のシークェンスを実行時に探索するようになっている．
さらにいけないのが，
マッチングの過程で変数束縛を保持するためにリストを一々コンシングしている点だ．
コンパイル時に知られている情報を活用して\verb|if-match|の新版を書けば，
不必要な比較を行わず，全くコンシングしないようにできる．

シークェンスの片方がコンパイル時に知られており，そちらだけが変数を含むときは，別のやり方で行ける．
\verb|match|を呼び出すときは，どちらの引数が変数を含んでもよいことになっている．
変数を\verb|if-match|の第1引数のみに制限することで，
コンパイル時にどの変数がマッチングに関わるかを判定できる．
すると変数束縛のリストを作らずに，変数の値を変数そのものの中に保持することができる．

\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro if-match (pat seq then &optional else)
  `(let ,(mapcar #'(lambda (v) `(,v ',(gensym)))
                 (vars-in pat #'simple?))
     (pat-match ,pat ,seq ,then ,else)))

(defmacro pat-match (pat seq then else)
  (if (simple? pat)
      (match1 `((,pat ,seq)) then else)
      (with-gensyms (gseq gelse)
                    `(labels ((,gelse () ,else))
                       ,(gen-match (cons (list gseq seq)
                                         (destruc pat gseq #'simple?))
                                   then
                                   `(,gelse))))))

(defun simple? (x) (or (atom x) (eq (car x) 'quote)))

(defun gen-match (refs then else)
  (if (null refs)
      then
      (let ((then (gen-match (cdr refs) then else)))
        (if (simple? (caar refs))
            (match1 refs then else)
            (gen-match (car refs) then else)))))

(defun match1 (refs then else)
  (dbind ((pat expr) . rest) refs
         (cond ((gensym? pat)
                `(let ((,pat ,expr))
                   (if (and (typep ,pat 'sequence)
                            ,(length-test pat rest))
                       ,then
                       ,else)))
               ((eq pat '_) then)
               ((var? pat)
                (let ((ge (gensym)))
                  `(let ((,ge ,expr))
                     (if (or (gensym? ,pat) (equal ,pat ,ge))
                         (let ((,pat ,ge)) ,then)
                         ,else))))
               (t `(if (equal ,pat ,expr) ,then ,else)))))

(defun gensym? (s)
  (and (symbolp s) (not (symbol-package s))))

(defun length-test (pat rest)
  (let ((fin (caadar (last rest))))
    (if (or (consp fin) (eq fin 'elt))
        `(= (length ,pat) ,(length rest))
        `(> (length ,pat) ,(- (length rest) 2)))))
\end{FramedVerb}\end{center}
\caption{高速マッチング・オペレータ．}
\label{fig:FastMatchOp}
\end{figure}

\verb|if-match|の新版は第\ref{fig:FastMatchOp}図に示した．
どのコードが実行時に評価されるか予測がつくときは，コンパイル時にコードを生成できる．
ここでは\verb|match|の呼び出しへ展開させる代わりに，必要な比較だけを行うコードを生成することにする．

変数\verb|?x|を使って\verb|?x|の束縛を保持するつもりなら，
まだマッチングによって束縛が決定されていない変数をどのように表現すればよいだろうか？
ここではパターン変数がgensymに束縛されているときに未束縛を表すことにする．
よって\verb|if-match|は，パターン内の変数を全てgensymに束縛するコードの生成から始まる．
この場合\verb|with-gensyms|へと展開せずに，コンパイル時に一度にgensymを生成して，
展開形内に直接挿入しても大丈夫だ．

展開形の残りは\verb|pat-match|が生成する．
このマクロは\verb|if-match|と同じ引数を取る．
唯一の違いは，こちらはパターン変数には新しい束縛を設けない点だ．
状況によってはこの方が都合がよい．
また第19章では\verb|pat-match|ならではの用法が出て来る．

新マッチングオペレータでは，
パターンの中身とパターンの構造との区別は関数\verb|simple?|によって定義される．
パターン内にクォートされたリテラルを使えるようにしたいなら，
構造化代入を行うコード（及び\verb|vars-in|）は，
第1要素がクォートであるリストの中には進まないように指示されなくてはならない．
新マッチング・オペレータでは，単にリストをクォートするだけでパターンの要素として使える．

\verb|dbind|と同様，\verb|pat-match|は\verb|destruc|を呼んで，
実行時に引数を切り分けてくれる関数呼び出しのリストを得ている．
このリストは，ネストしたパターン用のマッチングコードを再帰的に生成する\verb|gen-match|に渡され，
次に，パターンのツリーの葉それぞれに対するマッチングコードを生成する\verb|match1|に渡される．

\verb|if-match|の展開形内のコードの大部分は，第\ref{fig:FastMatchOp}図の\verb|match1|に因るものだ．
この関数は4通りの場合を考慮している．
パターンの要素がgensymのときは，
それは部分リストの保持のために\verb|destruc|に作られた不可視な変数の一つであって，
実行時に行う必要があるのは，それが適切な長さを持っているか調べることだけだ．
要素がワイルドカード（\,\verb|_|\,）のときは，コードを生成する必要はない．
要素が変数のときは，\verb|match1|が，
その変数を実行時に与えられるシークェンスの対応する部分に対してマッチするコード
またはその変数に対応する部分を代入するコードを生成する．
これら以外のときは，要素はリテラル値として扱われ，
\verb|match1|はそれをシークェンスの対応する場所と比較するコードを生成する．

\begin{figure}\begin{center}
\fbox{~\,\begin{minipage}{\FrameWidth}\narrowbaselines
\vspace{3pt}
\begin{center}\begin{minipage}{240pt}\texttt{%
(if-match (?x 'a) seq\\
~~(print ?x))
}\end{minipage}\end{center}
\hspace{12zw}これは次のように展開される：
\begin{center}\begin{minipage}{260pt}\texttt{%
(let ((?x '\#:g1))\\
~~(labels ((\#:g3 nil nil))\\
~~~~(let ((\#:g2 seq))\\
~~~~~~(if (and (typep \#:g2 'sequence)\\
~~~~~~~~~~~~~~~(= (length \#:g2) 2))\\
~~~~~~~~~~(let ((\#:g5 (elt \#:g2 0)))\\
~~~~~~~~~~~~(if (or (gensym? x) (equal ?x \#:g5))\\
~~~~~~~~~~~~~~~~(let ((?x \#:g5))\\
~~~~~~~~~~~~~~~~~~(if (equal 'a (elt \#:g2 1))\\
~~~~~~~~~~~~~~~~~~~~~~(print ?x)\\
~~~~~~~~~~~~~~~~~~~~~~(\#:g3)))\\
~~~~~~~~~~~~~~~~(\#:g3)))\\
~~~~~~~~~~(\#:g3)))))
}\end{minipage}\end{center}
\vspace{1.3em}\end{minipage}~\,}\end{center}
\caption{\texttt{if-match}の展開形．}
\label{fig:ExpansionOfIfmatch}
\end{figure}

展開形の一部が生成される様子の例を見よう．
次のマクロ呼び出しから始める．
\begin{verbatim}
(if-match (?x 'a) seq
  (print ?x)
  nil)
\end{verbatim}
パターンは，シークェンスを表現する幾つかのgensym（読み易くするために\verb|g|と呼ぼう）
と共に\verb|destruc|に渡される．
\begin{verbatim}
(destruc '(?x 'a) 'g #'simple?)
\end{verbatim}
この結果は次のようになる．
\begin{verbatim}
((?x (elt g 0)) ((quote a) (elt g 1)))
\end{verbatim}
このリストの先頭に\verb|(g seq)|をコンスし，
\begin{verbatim}
((g seq) (?x (elt g 0)) ((quote a) (elt g 1)))
\end{verbatim}
この全体を\verb|gen-match|に送る．
\verb|length|のナイーヴな実装（grsページ）と同様に，
\verb|gen-match|は最初にリスト末尾までえんえんと再帰的に作用し，戻る過程で返り値を構築する．
要素が尽きると\verb|gen-match|はthen部を返すが，それが\verb|?x|になる．
再帰から戻る過程で，この返り値は\verb|match1|にthen部として渡される．
こうして次のような呼び出しが得られ，
\begin{verbatim}
(match1 '(((quote a) (elt g 1))) '(print ?x) ' else function )
\end{verbatim}
この結果は次のようになる．
\begin{verbatim}
(if (equal (quote a) (elt g 1))
    (print ?x)
    else function)
\end{verbatim}
今度はこれが\verb|match1|の別の呼び出しのthen部になり，
その値が最後の\verb|match1|のthen部になる．
この\verb|if-match|の展開形の全貌は第\ref{fig:ExpansionOfIfmatch}図に示した．

この展開形では，gensymは全く関連のない2通りで使われている．
まず実行時にツリーの一部を保持する変数は，捕捉を避けるためにgensymの名前を持っている．
また変数\verb|?x|の初期値には，
マッチングによって値を代入されていないことを表すためgensymが使われる．

新しい\verb|if-match|では，パターンの要素は，暗黙の内にクォートされずに評価される．
これはLispの変数が，クォートされた式と同様にパターン内に使えるということだ．
\begin{verbatim}
> (let ((n 3))
    (if-match (?x n 'n '(a b)) '(1 3 n (a b))
      ?x))
1
\end{verbatim}

新版は\verb|destruc|（第\ref{fig:GeneralSeqDestructuringOp}図）を呼んでいるので，
改善点がさらに2つ出て来る．
パターンにキーワード\verb|&rest|や\verb|&body|が使えるようになった
（\verb|match|はこれらがあって問題にはならない）．
また\verb|destruc|はシークェンス一般用のオペレータ\verb|elt|と\verb|subseq|を使っているので，
\verb|if-match|の新版はどのようなシークェンスについても使える．
\verb|abab|が新版\verb|if-match|で定義されると，ヴェクタや文字列にも使えるようになる．
\begin{verbatim}
> (abab "abab")
#\a
#\b
> (abab #(1 2 1 2))
1 2
\end{verbatim}
実際，パターンは\verb|dbind|に渡せるものと同じ位複雑であってもよい．
\begin{verbatim}
> (if-match (?x (1 . ?y) . ?x) '((a b) #(1 2 3) a b)
    (values ?x ?y))
(A B)
#(2 3)
\end{verbatim}
第2返り値でヴェクタの要素が表示されていることに注意．
ヴェクタをこのように表示するには，\verb|*print-array*|を\verb|t|に設定すること．

この章では，プログラミングの新たな領域への一歩を踏み出した．
構造化代入のための単純なマクロから話は始まった．
\verb|if-match|の最終版では，むしろ独自の言語に見えるようなものが得られた．
以降の章では，同じ考えに基づいて働く種類のプログラム全体について説明する．
%}}}
%}}}
\section{クエリ・コンパイラ} % {{{
前章で定義したマクロの幾つかは大規模なものだった．
\verb|if-match|の展開形を得るためには，\reffig{fig:FastMatchOp}のコード全てに加え，
\reffig{fig:GeneralSeqDestructuringOp}の\verb|destruc|が必要になる．
これ位の大きさのマクロからは，最後の論点へと自然に話がつながる．
埋め込み言語だ．
小さなマクロがLispの拡張に当たるなら，
大規模なマクロはLisp内部に部分言語を定義している\wadash
そこには独自の構文や制御構造が備わっていることもある．
それへの第一歩を\verb|if-match|の中に見た．
これは変数を独自の方法で表現していた．

Lispの中に実装された言語は埋め込み言語と呼ばれる．
「ユーティリティ」と同様，この言葉に正確な定義はない．
\verb|if-match|は恐らくユーティリティに数えられようが，境界線にずいぶん近付いている．

埋め込み言語は，古典的なコンパイラやインタプリタで実装された言語とは異なる．
それは既存のプログラミング言語の内部に，普通はコード変形を用いて実装される．
基盤のプログラミング言語と拡張部分の間に境界は必要ない．
二つは自由に交じり合わせることができるべきだ．
実装者にとっては，これは労力の大きな削減になり得る．
必要な部分だけを埋め込んで，残りは基盤となったプログラミング言語を利用すればよい．

Lispにおいては，コード変形はマクロを示唆する．
プリプロセッサを用いても，ある程度は埋め込み言語を実装できる．
しかし普通プリプロセッサはテキストにのみ作用するが，
マクロはLispの独特な性質を活用できる．
リーダとコンパイラの間では， LispプログラムはLispのオブジェクトのリストとして表現される．
この段階でコード変形を非常に巧く行うことができる．

埋め込み言語の例で一番有名なのは，CLOSすなわちCommon Lisp Object Systemだ．
既存の言語のオブジェクト指向版が欲しくなったら，新しいコンパイラを書かなければならないだろう．
Lispではそうではない．
コンパイラのチューニングはCLOSの性能を向上させるだろうが，
原則的にはコンパイラを変更する必要は一切ない．
全てをLispで書くことができる．

以降の章では埋め込み言語の例を示す．
この章ではLispの中にデータベースへのクエリに答えるプログラムを埋め込む方法を説明する．
（そのプログラムはある意味で\verb|if-match|と似ていることに気づくだろう．）
第1節ではクエリを解釈するシステムの書き方を説明する．
さらにそのプログラムをクエリ・コンパイラ\wadash
本質的には1つの大きなマクロ\wadash として再実装する．
すると効率は向上し，Lispとの統合性も高まる．
\subsection{データベース}   %{{{
当面の目標のためには，データベースのスキーマは大した問題にならない．
ここでは簡便さを取り，情報をリストの形で保存することにする．
例えばJoshua Reynoldsが英国人画家で，1723年から1792年まで生きたという事実は，次のように表現する．
\begin{verbatim}
(painter reynolds joshua english)
(dates reynolds 1723 1792)
\end{verbatim}
情報をリストにまとめる決まった方法はない．
大きな1つのリストを使ってもよいだろう．
\begin{verbatim}
(painter reynolds joshua 1723 1792 english)
\end{verbatim}

データベースのエントリをどのように構成するかはユーザ次第だ．
唯一の制限は，エントリ（事実）は第1要素（述語）をキーに区別されるということだ．
その制限に従う限りどんな形式でも一貫性があればよい．
ただ，形式によってクエリへの反応に速い遅いの違いが出ることがある．

\begin{figure}\begin{center}\begin{FramedVerb}
(defun make-db (&optional (size 100))
  (make-hash-table :size size))

(defvar *default-db* (make-db))

(defun clear-db (&optional (db *default-db*))
  (clrhash db))

(defmacro db-query (key &optional (db '*default-db*))
  `(gethash ,key ,db))

(defun db-push (key val &optional (db *default-db*))
  (push val (db-query key db)))

(defmacro fact (pred &rest args)
  `(progn (db-push ',pred ',args)
          ',args))
\end{FramedVerb}\end{center}
\caption{データベースの基本となる関数．}
\label{fig:BasicDatabaseFunc}
\end{figure}

どのデータベースにも最低2つの機能が必須だ．
すなわちデータベースの内容の修正と，内容の問い合わせだ．
\reffig{fig:BasicDatabaseFunc}のコードはそれらの機能を基本的な形で提供する．
データベースは，事実のリストから成り，それらの述語をキーとするハッシュ表で表現される．

\reffig{fig:BasicDatabaseFunc}で定義されたデータベース関数は複数のデータベースに対応しているが，
デフォルトでは\verb|*default-db*|に対して作用する．
Common Lispのパッケージシステムと同様，
複数のデータベースが必要でないプログラムはどのデータベースを使うかについて一切触れる必要がない．
この節では，全ての例で\verb|*default-db*|のみを使う．

システムの初期化には\verb|clear-db|を呼ぶ．
これは現在使っているデータベースを空にする．
与えられた述語から事実を検索するには\verb|db-query|を，
新しい事実をデータベースのエントリに挿入するには\verb|db-push|を使う．
第12.1節で説明したように，
インヴァージョン可能な参照に展開されるマクロはそれ自身インヴァージョン可能だ．
\verb|db-query|はそのように定義されているので，
述語で\verb|db-query|を呼んだ結果に\verb|push|で新しい事実をただプッシュすればよい．
Common Lispではハッシュ表のエントリは（指定のない限り）\verb|nil|に初期化されるので，
どのキーにも最初には空リストが関連付けられている．
最後に，マクロ\verb|fact|がデータベースに新しい事実を追加する．

\begin{verbatim}
> (fact painter reynolds joshua english)
(REYNOLDS JOSHUA ENGLISH)
> (fact painter canale antonio venetian)
(CANALE ANTONIO VENETIAN)
> (db-query 'painter)
((CANALE ANTONIO VENETIAN)
     (REYNOLDS JOSHUA ENGLISH))
T
\end{verbatim}

\verb|db-query|の第2返り値として\verb|t|が返されているのは，
\verb|db-query|が\verb|gethash|に展開されるせいだ．
エントリが見つからない場合と，値が\verb|nil|のエントリを発見した場合を区別するため，
\verb|gethash|は第2返り値にフラグを返す．
%}}}
\subsection{Pattern-Matchingクエリ}   %{{{
\verb|db-query|を呼ぶのは，データベースの利用方法としては柔軟さに欠ける．
普通，ユーザは事実の第1要素だけに依存する質問だけをするのではない．
クエリ言語とは，複雑な質問を表現するための言語だ．
典型的なクエリ言語では，
ユーザは条件の適当な組合せを満たす全ての値を検索できる．
例えば「1697年生まれの全ての画家の名字」だ．

\begin{figure}\begin{center}\begin{FramedVerb}
query    : (symbol  argument *)
         : (not  query )
         : (and  query *)
         : (or  query *)
argument : ? symbol
         :  symbol
         :  number
\end{FramedVerb}\end{center}
\caption{クエリの文法}
\label{fig:SytaxOfQuery}
\end{figure}

これから宣言的クエリ言語を提供するプログラムを作る．
宣言的クエリ言語では，答えが満たす必要のある条件をユーザが指定し，システムに答えの生成を任せる．
このようなクエリの表現は，私達が日常会話で使う形式に近い．
我々のプログラムでは，
\verb|(painter x ...)|という形の事実と\verb|(dates x 1697 ...)|という形の事実が
存在するような全ての\verb|x|を探すよう命じることでクエリを表現できるようにしよう．
1697年生まれの全ての画家を指定するには，次のようにする．
\begin{verbatim}
(and (painter ?x ?y ?z)
        (dates ?x 1697 ?w))
\end{verbatim}
我々のプログラムは，述語と幾つかの引数から成る単純なクエリの他，
\verb|and|，\verb|or|等の論理演算子で組み合わされた任意の複雑なクエリに解答できるようにする．
クエリ言語の文法は\reffig{fig:SytaxOfQuery}に示した．

事実は述語で区別されるので，変数が述語の位置に来ることはできない．
述語について順番付けのできる利点を諦めてよいなら，
常に同じ述語を使い，第1引数を事実上の述語として扱うことでこの制限を回避できる．

類似の多くのシステムと同様に，このプログラムは事実に対して懐疑的だ．
分かっている幾つかの事実の他は偽であるとする．
演算子\verb|not|は，問われた事実がデータベース内にないときにマッチに成功する．
「偽」ということを明示的に指定するには，Wayne's Worldの方法がある程度使える．
\begin{verbatim}
(edible motor-oil not)
\end{verbatim}
しかし演算子\verb|not|はこれらの事実を他の事実と全く同様に扱う．

プログラミング言語にとって，インタプリタとコンパイラの違いは根元的だ．
この章では，クエリについて同じ疑問を再び考える．
クエリ・インタプリタは受け取ったクエリを元にデータベースから答えを引き出す．
クエリ・コンパイラはクエリを受け取って，実行時に同じ結果を与えるプログラムを生成する．
以降の節ではまずクエリ・インタプリタを，次にクエリ・コンパイラを説明する．
%}}}
\subsection{クエリ・インタプリタ}   %{{{
\begin{figure}\begin{center}\begin{FramedVerb}
(defmacro with-answer (query &body body)
  (let ((binds (gensym)))
       `(dolist (,binds (interpret-query ',query))
             (let ,(mapcar #'(lambda (v)
                                 `(,v (binding ',v ,binds)))
                             (vars-in query #'atom))
              ,@body))))

(defun interpret-query (expr &optional binds)
  (case (car expr)
       (and (interpret-and (reverse (cdr expr)) binds))
       (or      (interpret-or (cdr expr) binds))
       (not (interpret-not (cadr expr) binds))
       (t       (lookup (car expr) (cdr expr) binds))))

(defun interpret-and (clauses binds)
  (if (null clauses)
        (list binds)
        (mapcan #'(lambda (b)
                       (interpret-query (car clauses) b))
                   (interpret-and (cdr clauses) binds))))

(defun interpret-or (clauses binds)
  (mapcan #'(lambda (c)
                   (interpret-query c binds))
                clauses))

(defun interpret-not (clause binds)
  (if (interpret-query clause binds)
        nil
        (list binds)))

(defun lookup (pred args &optional binds)
  (mapcan #'(lambda (x)
                   (aif2 (match x args binds) (list it)))
                (db-query pred)))
\end{FramedVerb}\end{center}
\caption{クエリ・インタプリタ．}
\label{fig:QueryInterpreter}
\end{figure}

宣言的クエリ言語を実装するために，
第18.4節で定義したパターンマッチング・ユーティリティを使う．
\reffig{fig:QueryInterpreter}に示した関数は，\reffig{fig:SytaxOfQuery}に示した形のクエリを解釈する．
中核となる関数は\verb|interpret-query|で，複雑なクエリの構造に対し再帰的に動作し，
束縛を順々に生成する．
複雑なクエリの評価は，Common Lispの関数の引数の評価と同様，左から右の順で行われる．

再帰が事実を表すパターンまで辿り着くと，\verb|interpret-query|は\verb|lookup|を呼び出す．
ここでパターンマッチングが行われる．
関数\verb|lookup|は，述語と引数リストから成るパターンを引数に取り，
パターンがデータベース内のいずれかの事実にマッチするような束縛全てから成るリストを返す．
\verb|lookup|は述語に対応するデータベースのエントリそれぞれについて，
\verb|match|（xckページ）を呼んでパターンと比べる．
マッチが成功する度に束縛のリストが返されるが，
\verb|lookup|はそれらのリスト全てから成るリストを返す．

\begin{verbatim}
> (lookup 'painter '(?x ?y english))
(((?Y . JOSHUA) (?X . REYNOLDS)))
\end{verbatim}

\begin{figure}\begin{center}\begin{FramedVerb}
(clear-db)
(fact painter hogarth william english)
(fact painter canale antonio venetian)
(fact painter reynolds joshua english)
(fact dates hogarth 1697 1772)
(fact dates canale 1697 1768)
(fact dates reynolds 1723 1792)
\end{FramedVerb}\end{center}
\caption{事実の例．}
\label{fig:AssertionOfSampleFacts}
\end{figure}

これらの事実は，外側の論理演算子によって処理されたり組み合わされる．
最終結果は束縛の集合から成るリストとして返される．
\reffig{fig:AssertionOfSampleFacts}に示した事実があるとして，
この章の始めの方で示した例を実行してみた．
\begin{verbatim}
> (interpret-query '(and (painter ?x ?y ?z)
                         (dates ?x 1697 ?w)))
(((?W . 1768) (?Z . VENETIAN) (?Y . ANTONIO) (?X . CANALE))
 ((?W . 1772) (?Z . ENGLISH) (?Y . WILLIAM) (?X . HOGARTH)))
\end{verbatim}

一般則として，クエリを組み合わせたり入れ子にする際に制限はない．
場合によってはクエリの文法の些細な制限が顕在化するが，
その点についてはこのコードの使われ方の例を幾つか見た後に考えた方がよい．

マクロ\verb|with-answer|は，このクエリ・インタプリタをLispプログラム内でうまく使う方法を提供する．
第1引数には任意の可能なクエリを取り，残りの引数は本体コードとなる．
\verb|with-answer|は，クエリの生成した束縛全てを集め，
クエリ内の変数をそれぞれの束縛が指定する通りに束縛して本体コードを繰り返すコードに展開される．
\verb|with-answer|に渡したクエリ内に出て来る変数は（大抵は）本体コード内でも使える．
クエリが，成功はするものの変数を含まないときは，\verb|with-answer|は本体コードを1度だけ評価する．

\begin{figure}\begin{center}
\fbox{~\,\begin{minipage}{\FrameWidth}\narrowbaselines
\vspace{3pt}\hspace{8zw}Hogarthという名字の全ての画家のファーストネームと国籍．
\begin{center}\begin{minipage}{240pt}\texttt{%
> (with-answer (painter hogarth ?x ?y)\\
     (princ (list ?x ?y)))\\
(WILLIAM ENGLISH)\\
NIL
}\end{minipage}\end{center}
\hspace{8zw}1697年に生まれた全ての画家のラストネーム．（最初に提示した例）
\begin{center}\begin{minipage}{240pt}\texttt{%
> (with-answer (and (painter ?x \_ \_)\\
                    (dates ?x 1697 \_))\\
    (princ (list ?x)))\\
(CANALE)(HOGARTH)\\
NIL
}\end{minipage}\end{center}
\hspace{8zw}1772年または1792年に亡くなった人のラストネームと誕生年．
\begin{center}\begin{minipage}{240pt}\texttt{%
> (with-answer (or (dates ?x ?y 1772)\\
                   (dates ?x ?y 1792))\\
    (princ (list ?x ?y)))\\
(HOGARTH 1697)(REYNOLDS 1723)\\
NIL
}\end{minipage}\end{center}
\hspace{8zw}ヴェネツィアの画家の誰とも同じ年に生まれていない全ての英国人画家のラストネーム．
\begin{center}\begin{minipage}{240pt}\texttt{%
> (with-answer (and (painter ?x \_ english)\\
                    (dates ?x ?b \_)\\
                    (not (and (painter ?x2 \_ venetian)\\
                              (dates ?x2 ?b \_))))\\
    (princ ?x))\\
REYNOLDS\\
NIL
}\end{minipage}\end{center}
\vspace{1.3em}\end{minipage}~\,}\end{center}
\caption{クエリ・インタプリタの用例．}
\label{fig:QueryInterpreterInUse}
\end{figure}

\reffig{fig:AssertionOfSampleFacts}で定義したデータベースの下でクエリを行った例を，
\reffig{fig:QueryInterpreterInUse}に，自然言語への翻訳付きで示した．
パターンマッチングが\verb|match|によって行われているため，
パターン内でアンダースコア（下線，\verb|_|）をワイルドカードとして使える．

例を長くしないために，クエリの本体内では結果の表示以外のことを行っていない．
しかし，一般には\verb|with-answer|の本体には任意のLispの式が使える．
%}}}
\subsection{束縛に関する制限}   %{{{
クエリが変数を束縛する際に制限が幾つかある．
例えば次のクエリは，
\begin{verbatim}
(not (painter ?x ?y ?z))
\end{verbatim}
どうして\verb|?x|と\verb|?y|に束縛を一切与えないのだろう？\
画家の内の誰かの名前でない\verb|?x|と\verb|?y|には無限通りの組合せがある．
よって，次の制限を加えることにする．
演算子\verb|not|は，次のように，既に生成された束縛に対して処理を行うが，
\begin{verbatim}
(and (painter ?x ?y ?z) (not (dates ?x 1772 ?d)))
\end{verbatim}
それ自身だけで束縛を作ってくれるものではない．
画家を探して束縛の集合を生成しなければならないわけだが，
それをするのは1772年に生まれていない人物を選び出せるようになる前だ．
節を逆順に指定していたら，
\begin{verbatim}
(and (not (dates ?x 1772 ?d)) (painter ?x ?y ?z))                        ; wrong
\end{verbatim}
1772年に生まれた画家が一人でもいたら結果として\verb|nil|を得るだろう．
第1の例ですら，\verb|?d|の値が\verb|with-answer|式の内部で使えると期待してはならないのだ．

また\verb|(or q1 ... qn)|という形の式では，
束縛が与えられることが保証されているのは全ての\verb|qi|の中に現れる変数に対してのみだ．
\verb|with-answer|に次の形のクエリが含まれていたとき，
\begin{verbatim}
(or (painter ?x ?y ?z) (dates ?x ?b ?d))
\end{verbatim}
\verb|?x|には必ず束縛が与えられる．
2つの部分クエリのどちらが成功しても，\verb|?x|には束縛が与えられるからだ．
しかし\verb|?y|と\verb|?b|のいずれについても，クエリが束縛を与える保証はない．
（どちらか片方は必ず束縛が与えられるのだが．）
クエリが束縛を与えなかったパターン変数は，繰り返しの内のその回の間は\verb|nil|になる．
%}}}
\subsection{クエリ・コンパイラ}   %{{{
\reffig{fig:QueryInterpreter}のコードは所望の動作を実現するが，効率がよくない．
これはクエリの構造を実行時に解析しているが，構造はコンパイル時にもう分かっている．
また，変数束縛を保持するためにリストをコンシングしているが，変数自身に値を持たせてもよいはずだ．
どちらの問題点も，\verb|with-answer|の別の実装で解決できる．

\begin{figure}\begin{center}\begin{FramedVerb}
 (defmacro with-answer (query &body body)
   `(with-gensyms ,(vars-in query #'simple?)
         ,(compile-query query `(progn ,@body))))

 (defun compile-query (q body)
   (case (car q)
        (and (compile-and (cdr q) body))
        (or     (compile-or (cdr q) body))
        (not (compile-not (cadr q) body))
        (lisp `(if ,(cadr q) ,body))
        (t      (compile-simple q body))))

 (defun compile-simple (q body)
   (let ((fact (gensym)))
        `(dolist (,fact (db-query ',(car q)))
              (pat-match ,(cdr q) ,fact ,body nil))))

 (defun compile-and (clauses body)
   (if (null clauses)
         body
         (compile-query (car clauses)
                              (compile-and (cdr clauses) body))))

 (defun compile-or (clauses body)
   (if (null clauses)
         nil
         (let ((gbod (gensym))
                  (vars (vars-in body #'simple?)))
               `(labels ((,gbod ,vars ,body))
                 ,@(mapcar #'(lambda (cl)
                                   (compile-query cl `(,gbod ,@vars)))
                              clauses)))))

 (defun compile-not (q body)
   (let ((tag (gensym)))
        `(if (block ,tag
                 ,(compile-query q `(return-from ,tag nil))
                 t)
               ,body)))
\end{FramedVerb}\end{center}
\caption{クエリ・コンパイラ．}
\label{fig:QueryCompiler}
\end{figure}

\reffig{fig:QueryCompiler}では新しい\verb|with-answer|を定義している．
新型は\verb|avg|（xlxページ）から始まり，\verb|if-match|（rezページ）へつながった傾向に沿っている．
すなわち，旧型が実行時に行っていた処理の大半をコンパイル時に行っている．
\reffig{fig:QueryCompiler}のコードは一見\reffig{fig:QueryInterpreter}のコードと似ているが，
その中のコードで実行時に呼ばれるものは一切ない．
束縛を生成するのではなく，\verb|with-answer|の展開形の一部をなすコードを生成する．
実行時には，そのコードはデータベースの現状に基づいてクエリを満たす全ての束縛を生成する．

\begin{figure}\begin{center}
\fbox{~\,\begin{minipage}{\FrameWidth}\narrowbaselines
\vspace{3pt}
\begin{center}\begin{minipage}{240pt}\texttt{%
(with-answer (painter ?x ?y ?z)\\
~~(format t "\~{}A \~{}A is a painter.~{}\%" ?y ?x))
}\end{minipage}\end{center}
\hspace{8zw}これはクエリ・インタプリタにより次のように展開される：
\begin{center}\begin{minipage}{280pt}\texttt{%
(dolist (\#:g1 (interpret-query '(painter ?x ?y ?z)))\\
~~(let ((?x (binding '?x \#:g1))\\
~~~~~~~~(?y (binding '?y \#:g1))\\
~~~~~~~~(?z (binding '?z \#:g1)))\\
~~~~(format t "\~{}A \~{}A is a painter.\~{}\%" ?y ?x)))
}\end{minipage}\end{center}
\hspace{8zw}そしてクエリ・コンパイラにより次のように展開される：
\begin{center}\begin{minipage}{280pt}\texttt{%
(with-gensyms (?x ?y ?z)\\
~~(dolist (\#:g1 (db-query 'painter))\\
~~~~(pat-match (?x ?y ?z) \#:g1\\
~~~~~~(progn\\
~~~~~~~~(format t "\~{}A \~{}A is a painter.\~{}\%" ?y ?x))\\
~~~~~~~~nil)))\\
}\end{minipage}\end{center}
\vspace{1.3em}\end{minipage}~\,}\end{center}
\caption{同じクエリの2通りの展開形．}
\label{fig:TwoExpansionsOftheSameQuery}
\end{figure}

実際のところ，このプログラムは一つの巨大なマクロなのだ．
\reffig{fig:TwoExpansionsOftheSameQuery}には\verb|with-answer|の展開形を示した．
処理の大半は\verb|pat-match|（wgcページ）が行うが，それもまたマクロだ．
すると実行時に必要になる新たな関数は，
\reffig{fig:BasicDatabaseFunc}に示した基本的データベース関数だけだ．

\verb|with-answer|がトップレベルから呼ばれると，クエリのコンパイルは利点をほとんど生かせない．
クエリを表現するコードは生成され，評価された後，廃棄される．
しかし\verb|with-answer|がLispプログラムの中で使われたときは，
クエリに対応するコードはマクロ展開の一部となる．
よっってそれを含むプログラムがコンパイルされたとき，
全てのクエリに対するコードがプロセスの中にインラインでコンパイルされる．

新手法の最大の利点は速度だが，
\verb|with-answer|を呼び出すコードとの統合性を高めることにもつながっている．
そのことは2か所の改善として現われる．
まず，クエリ内部の引数が評価されるようになるので，次のように書ける．
\begin{verbatim}
> (setq my-favorite-year 1723)
1723
> (with-answer (dates ?x my-favorite-year ?d)
        (format t "~A was born in my favorite year.~%" ?x))
REYNOLDS was born in my favorite year.
NIL
\end{verbatim}
クエリ・インタプリタでできない訳ではないが，\verb|eval|を明示的に呼ぶという代償を払わないといけない．
そのときでさえ，クエリ引数内のレキシカル変数を参照することは無理だ．

\begin{figure}\begin{center}
\fbox{~\,\begin{minipage}{\FrameWidth}\narrowbaselines
\vspace{3pt}\hspace{6zw}Hogarthという名字の全ての画家のファーストネームと国籍．
\begin{center}\begin{minipage}{320pt}\texttt{%
> (with-answer (painter 'hogarth ?x ?y)\\
~~~~(princ (list ?x ?y)))\\
(WILLIAM ENGLISH)\\
NIL
}\end{minipage}\end{center}
\hspace{6zw}ヴェネツィアのどの画家とも同じ年に生まれていない英国人画家のラストネーム．
\begin{center}\begin{minipage}{320pt}\texttt{%
> (with-answer (and (painter ?x \_ 'english)\\
~~~~~~~~~~~~~~~~~~~~(dates ?x ?b \_)\\
~~~~~~~~~~~~~~~~~~~~(not (and (painter ?x2 \_ 'venetian)\\
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~(dates ?x2 ?b \_))))\\
~~~~(princ ?x))\\
REYNOLDS\\
NIL
}\end{minipage}\end{center}
\hspace{6zw}1770年から1800年の間に亡くなった全ての画家のラストネームと没年．
\begin{center}\begin{minipage}{320pt}\texttt{%
> (with-answer (and (painter ?x \_ \_)\\
~~~~~~~~~~~~~~~~~~~~(dates ?x \_ ?d)\\
~~~~~~~~~~~~~~~~~~~~(lisp (< 1770 ?d 1800)))\\
~~~~(princ (list ?x ?d)))\\
(REYNOLDS 1792)(HOGARTH 1772)\\
NIL
}\end{minipage}\end{center}
\vspace{1.3em}\end{minipage}~\,}\end{center}
\caption{クエリ・コンパイラの用例．}
\label{fig:QueryCompilerInUse}
\end{figure}

クエリ内部の引数が評価されるようになり，
評価結果が自分自身にならない任意のリテラル引数（自然言語文など）にはクォートをつける必要がある．
（\reffig{fig:QueryCompilerInUse}を参照）

新手法の利点その2は，一般のLispの式をクエリ内に混ぜることがずっと容易になったことだ．
クエリ・コンパイラではオペレータ\verb|lisp|を追加されたが，それには任意のLisp式を続けることができる．
演算子\verb|not|と同様，\verb|lisp|自身は束縛を作れないが，
式が\verb|nil|を返すような束縛を選び出すことはできる．
オペレータ\verb|lisp|は \verb|>| などの組込み述語を利用するのに便利だ．
\begin{verbatim}
> (with-answer (and (dates ?x ?b ?d)
                    (lisp (> (- ?d ?b) 70)))
               (format t "~A lived over 70 years.~%" ?x))
CANALE lived over 70 years.
HOGARTH lived over 70 years.
NIL
\end{verbatim}

高度に作りこまれた埋め込み言語は，
基盤のプログラミング言語と一体化したインタフェイスを持つことができる．

これらの追加機能\wadash 引数の評価とオペレータ\verb|lisp|\wadash を除けば，
クエリ・コンパイラの提供するクエリ言語はインタプリタの提供するものと同じだ．
\reffig{fig:QueryCompilerInUse}には，
\reffig{fig:AssertionOfSampleFacts}で定義されたデータベースに基づいた
クエリ・コンパイラの動作結果の例を示した．

第17.2節では，式をコンパイルすることが\verb|eval|にリストとして渡すことより優れている理由を2つ挙げた．
コンパイルした方が速いし，式をその外側のレキシカル環境内で評価することができる．
クエリのコンパイルの利点も全く同じことだ．
今まで実行時に行われていた処理が，コンパイル時に行われるようになった．
クエリがその外側のLispコードの断片と共にコンパイルされるせいで，レキシカル・コンテキストが活用できる．
%}}}
% }}}
\section{継続} %{{{
継続とは，動作中に凍結したプログラムだ．
すなわち計算処理の状態を含んだ一つの関数的オブジェクトだ．
保存された計算処理は，それが中断された時点から再開する．
プログラムの状態を保存し，後に再開できる能力は，ある種の問題解決に素晴しい威力を発揮する．
例えば並列処理では，中断されたプロセスを継続で表すのが便利だ．
非決定的探索問題では，継続は探索ツリーのノードを表現できる．

継続の理解は難しいかも知れない．
この章ではその話題に2段階で取り組む．
この章の前半では継続の組込みサポートのあるSchemeでの用例を見る．
継続の振舞を説明し終わったら，後半ではCommon Lispプログラムで継続を生成するマクロの使い方を示す．
第22--24章のいずれでも，ここで定義したマクロを利用する．
\subsection{Schemeの継続}   %{{{
\begin{figure}\begin{center}
\fbox{~\,\begin{minipage}{\FrameWidth}\narrowbaselines
\vspace{3pt}
\begin{center}\begin{minipage}{.85\textwidth}
Common Lispでシンボルの「シンボル値」と「シンボル関数」と呼ぶものをSchemeでは区別しない．
Schemeの変数は単一の値を持つが，それは関数でも何らかのオブジェクトでもよい．
そのため，シャープ・クォートや\texttt{funcall}はSchemeでは必要ない．
Common Lispのこのコードは，
\\[4pt] \texttt{%
(let ((f \#'(lambda (x) (1+ x))))\\
~~(funcall f 2))\\[4pt]
}
Schemeでは次のようになる．
\\[4pt] \texttt{%
(let ((f (lambda (x) (1+ x))))
~~(f 2))\\[4pt]
}
Schemeの名前空間は1つだけなので，代入するためのオペレータがそれぞれ個別に
（\texttt{defun}と\texttt{setq}のように）存在しなくてもよい．
代わりに\texttt{defvar}に似た\texttt{define}と，
\texttt{setq}の代わりになる\texttt{set!}\,が存在する．
グローバル変数は\texttt{define}で定義してからでないと\texttt{set!}\,で値を設定できない．

Schemeでは名前の付いた関数は普通は\texttt{define}で定義される．
\texttt{defvar}だけでなく\texttt{defun}の役割もあるのだ．
Common Lispのこのコードは，
\\[4pt] \texttt{%
(defun foo (x) (1+ x))\\[4pt]
}
Schemeでは2通りに書ける．
\\[4pt] \texttt{%
(define foo (lambda (x) (1+ x)))\\
(define (foo x) (1+ x))
} \vspace*{4pt}

Common Lispでは，関数の引数は左から右の順に評価される．
Schemeでは評価順は意図的に未定義とされた．
（それを忘れた人間は慌てふためいて実装者の笑いものになる．）

\texttt{t}と\texttt{nil}の代わりに，Schemeには\,\texttt{\#t}と\,\texttt{\#f}がある．
空リスト\texttt{()}を真に評価する処理系もあれば
偽に評価する処理系もある．

オペレータ\texttt{cond}では\texttt{default}節，オペレータ\texttt{case}ではキー\texttt{else}が使えるが，
これらはCommon Lispの\texttt{t}の役割を持つ．

組込みオペレータの名前が違う．\texttt{consp}が\texttt{pair?}で\texttt{null}が\texttt{null?}，
\texttt{mapcar}は（ほぼ）\texttt{map}に対応する，等．
普通，文脈から違いは明らかだ．
\end{minipage}\end{center}
\vspace{1.3em}\end{minipage}~\,}\end{center}
\caption{SchemeとCommon Lispの相異点．}
\label{fig:SomeDifferences}
\end{figure}

SchemeとCommon Lispの主要な相異点には，継続を明示的にサポートする点がある．
この節ではSchemeで継続がどのように動作するかを示す．
（\reffig{fig:SomeDifferences}にはSchemeとCommon Lispの他の相異点を列挙した．）

継続は計算処理の未来を表現する関数だ．
式が評価されるときには，必ず何かがその返り値を待っている．
例えば次のコードで\verb|(- x 1)|が評価された時点では，
\begin{verbatim}
(/ (- x 1) 2)
\end{verbatim}
外側の \verb|/| 式がその値を待っており，さらに別の何かが \verb|/| 式の値を待っている\ldots
等が，\verb|print|の待っているトップレベルまで延々と続く．

任意の時点の継続は，1引数関数と考えられる．
上の例がトップレベルに打ち込まれたとき，
部分式\verb|(- x 1)|が評価された時点での継続は次のように考えられる．
\begin{verbatim}
(lambda (val) (/ val 2))
\end{verbatim}
すなわち計算処理の残りは\verb|(- x 1)|の返り値を上の関数に与えることで模倣できる．
また，式\verb|(- x 1)|が次の文脈の中に現われており，\verb|f1|がトップレベルから呼ばれた場合は，
\begin{verbatim}
(define (f1 w)
  (let ((y (f2 w)))
    (if (integer? y) (list 'a y) 'b)))

(define (f2 x)
  (/ (- x 1) 2))
\end{verbatim}
\verb|(- x 1)|が評価された時点での継続は次のようになる．
\begin{verbatim}
(lambda (val)
  (let ((y (/ val 2)))
    (if (integer? y) (list 'a y) 'b)))
\end{verbatim}

Schemeでは，継続は関数と同格のファーストクラス・オブジェクトだ．
Schemeでは現在の継続 (current continuation) を求めると計算処理の未来を表現する1引数関数が得られる．
このオブジェクトは好きなように保存できるし，
保存した継続を呼び出せば，それが生成された時点で始まろうとしていた計算処理を再開する．

継続はクロージャの一般化として理解できる．
クロージャとは，関数とそれが生成された時点で見えていたレキシカル変数へのポインタをまとめたものだった．
継続とは，関数とそれが生成された時点で溜っているスタック全体へのポインタをまとめたものだ．
継続が評価されると，現在のスタックを無視し，それが保持しているスタックのコピーに基づいて値を返す．
継続が\verb|T1|で生成され\verb|T2|で評価された場合，
\verb|T1|において溜っているスタックに基づいた評価が行われる．

Schemeプログラムは組込みオペレータ\verb|call-with-current-continuation|（略して\verb|call/cc|）
を通じて現在の継続にアクセスできる．
プログラムが\verb|call/cc|を1引数関数に対して呼び出すと，
\begin{verbatim}
(call-with-current-continuation
  (lambda (cc)
    ...))
\end{verbatim}
その1引数関数には現在の継続を表現する別の関数が渡される．
上で\verb|cc|の値をどこかに保存することで，\verb|call/cc|の時点での計算処理の状態が保存できる．

上の例では，
最後の要素が\verb|call/cc|式の返り値であるようなリストに\verb|append|を適用している．
\begin{verbatim}
> (define frozen)
FROZEN
> (append '(the call/cc returned)
          (list (call-with-current-continuation
                  (lambda (cc)
                    (set! frozen cc)
                    'a))))
(THE CALL/CC RETURNED A)
\end{verbatim}
\verb|call/cc|は\verb|a|を返すが，最初に継続をグローバル変数\verb|frozen|に保存する．

\verb|frozen|を呼び出すと，\verb|call/cc|の時点での古い計算が再開される．
\verb|frozen|に渡した値は，いずれも\verb|call/cc|の返り値になる．
\begin{verbatim}
> (frozen 'again)
(THE CALL/CC RETURNED AGAIN)
\end{verbatim}

継続は，評価されても消費はされない．他の普通の関数と同様，繰りかえし呼ぶこともできる．
\begin{verbatim}
> (frozen 'thrice)
(THE CALL/CC RETURNED THRICE)
\end{verbatim}

継続を他の処理の内部で呼ぶとき，古いスタックに立ち戻ることの意味がはっきり見えるようになる．
\begin{verbatim}
> (+ 1 (frozen 'safely))
(THE CALL/CC RETURNED SAFELY)
\end{verbatim}
ここでは，\verb|frozen|が呼ばれると結果を待っている \verb|+| は無視される．
\verb|frozen|は，最初に生成された時点で溜っていたスタックに従い，
まず\verb|list|，次に\verb|append|を通じ，トップレベルまで戻る．
\verb|frozen|が普通の関数呼び出しと同様に値を返していたら，
上の式は \verb|+| が\verb|1|をリストに足し算しようとしたことでエラーになっていただろう．

継続はスタックのコピーを個別に保持するのではない．
他の継続や，進行中の計算処理と変数を共有できる．
次の例では，2つの継続が同じスタックを共有している．
\begin{verbatim}
> (define froz1)
FROZ1
> (define froz2)
FROZ2
> (let ((x 0))
    (call-with-current-continuation
      (lambda (cc)
        (set! froz1 cc)
        (set! froz2 cc)))
    (set! x (1+ x))
    x)
1
\end{verbatim}
よってどちらを呼んでも1ずつ増える数列が得られる．
\begin{verbatim}
> (froz2 ())
2
> (froz1 ())
3
\end{verbatim}
\verb|call/cc|式の値は破棄されるので，\verb|froz1|や\verb|froz2|に与える引数は何でもよい．

\begin{figure}\begin{center}\begin{FramedVerb}


\end{FramedVerb}\end{center}
\caption{2つのツリー}
\label{fig:TwoTrees}
\end{figure}

さて，計算処理の状態を保存できるようになった訳だが，それで何をすればよいのだろう？\
第21--24章は継続を使うアプリケーションに充てられている．
ここでは「保存された状態」を使うプログラミングの雰囲気がよく現われる単純な例を考えよう．
ツリーの集合が与えられたとき，
各ツリーから要素を1つずつ取って作ったリストを，何らかの条件を満たす組合せになるまで生成しよう．

ツリーは入れ子になったリストとして表現できる．
grqページではある種のツリーをリストとして表現する方法を説明した．
ここでは別の方法を使い，内部ノードが（アトムの）値を持て，任意個の子を持てるようにした．
この表現では，内部ノードはリストになる．
Car部はノードとしての値を保持し，cdr部はそのノードの子の表現を保持する．
例えば\reffig{fig:TwoTrees}の2つのツリーは次のように表現できる．
\begin{verbatim}
(define t1 '(a (b (d h)) (c e (f i) g)))
(define t2 '(1 (2 (3 6 7) 4 5)))
\end{verbatim}

\begin{figure}\begin{center}\begin{FramedVerb}
(define (dft tree)
  (cond ((null? tree) ())
        ((not (pair? tree)) (write tree))
        (else (dft (car tree))
              (dft (cdr tree)))))

(define *saved* ())

(define (dft-node tree)
  (cond ((null? tree) (restart))
        ((not (pair? tree)) tree)
        (else (call-with-current-continuation
                (lambda (cc)
                  (set! *saved*
                    (cons (lambda ()
                            (cc (dft-node (cdr tree))))
                          *saved*))
                  (dft-node (car tree)))))))

(define (restart)
  (if (null? *saved*)
      'done
      (let ((cont (car *saved*)))
        (set! *saved* (cdr *saved*))
        (cont))))

(define (dft2 tree)
  (set! *saved* ())
  (let ((node (dft-node tree)))
    (cond ((eq? node 'done) ())
          (else (write node)
                (restart)))))
\end{FramedVerb}\end{center}
\caption{継続を使ったツリーの探索．}
\label{fig:TraversalUsingCont}
\end{figure}

\reffig{fig:TraversalUsingCont}にはそのようなツリーに対して深さ優先探索を行う関数を示した．
実際のプログラムでは，ノードに行き着くごとにそれに対して何かの処理をしたくなる．
ここでは単に表示するだけだ．
比較に用いる関数\verb|dft|は，通常の深さ優先探索を行う．
\begin{verbatim}
> (dft t1)
ABDHCEFIG()
\end{verbatim}

関数\verb|dft-node|の方は，ツリーの辿り方は同じだがノードを個別に扱う．
\verb|dft-node|がノードに達すると，ノードのcar部に進み，
cdr部を探索するという継続を \verb|*saved*| にプッシュする．
\begin{verbatim}
> (dft-node t1)
A
\end{verbatim}
\verb|restart|を呼ぶと最後に保存された継続をポップして呼び出すことで探索が再開される．
\begin{verbatim}
> (restart)
B
\end{verbatim}
最後に保存された状態が使い果たされると，\verb|restart|は\verb|done|を返すことでそれを知らせる．
\begin{verbatim}
...> (restart)
G> (restart)
DONE
\end{verbatim}
最後に，関数\verb|dft2|は上で手動で行っていたことをきれいに隠蔽する．
\begin{verbatim}
> (dft2 t1)
ABDHCEFIG()
\end{verbatim}

\verb|dft2|の定義には明示的な再帰も反復もないことに注意．
ノードが次々と表示されるのは，\verb|restart|の呼び出した継続により，
必ず\verb|dft-node|の同じ\verb|cond|節にまで戻るからだ．

この種のプログラムは鉱脈のように働く．
\verb|dft-node|を呼び出すことで最初の穴を掘る．
返り値が\verb|done|でない限り，\verb|dft-node|の呼び出しに続くコードは\verb|restart|を呼び，
それが再びスタックに制御を送る．
（訳注: このあたりは曖昧な表現が多くて意味不明）
この経過はまで返り値が鉱脈は空であると知らせるまで継続する．
その値を表示する代わりに，\verb|dft2|は\verb|#f|を返す．
継続による探索は，プログラムに関する新たな考え方を表現している．
適切なコードをスタックに入れ，繰りかえしそこに戻ることで結果を手にするのだ．

\verb|dft2|のように一度に一つのツリーしか扱わないなら，この手法にこだわる理由はない．
\verb|dft-node|の利点は同時に複数の処理を進行させられることだ．
2つのツリーに対し，深さ優先探索で要素の直積を得たいとしよう．
\begin{verbatim}
> (set! *saved* ())
()
> (let ((node1 (dft-node t1)))
        (if (eq? node1 'done)
             'done
             (list node1 (dft-node t2))))
(A 1)
> (restart)
(A 2)
...
> (restart)
(B 1)
...
\end{verbatim}
普通の手法を使うと，
2つのツリーにおける位置を保存する段階を明示的に踏む必要がある．
継続を使うと，2つの実行中の探索の状態は自動的に扱われる．
このような単純な例では，ツリー中の位置を保存することは大して難しくない．
ツリーは不変なデータ構造だから，ツリー内の「自分の場所」を把握する方法は少なくとも何かある．
継続がすばらしいのは，対応する不変なデータ構造がない場合ですら，
任意の計算処理の途中で容易に進み具合を保存できる点だ．
計算処理の状態は，再開したいものが有限個である限り，有限個である必要すらない．

第24章で見るように，それらの考慮の両方がPrologの実装で重要だと分かる．
Prologプログラムではプログラムが結果を生成する上での「探索ツリー」は実際のデータ構造ではなく，
暗黙のものである．
それらツリーはしばしば無限の大きさを持つが，
その場合，あるツリー全体の探索を，別のツリーの探索の前に行うことは期待できない．
どうにかして「場所」を保存する他に選択肢はないのだ．
%}}}
\subsection{継続渡しマクロ}   %{{{
Common Lispは\verb|call/cc|を提供しないが，少々の労力でSchemeと同じことができるようになる．
この節では，マクロを使ってCommon Lispプログラムで継続を実現する方法を示す．
Schemeの継続は2種類のものを提供してくれた．
\begin{enumerate}
    \item 継続が生成された時点での全ての変数の束縛．
    \item 計算処理の状態\wadash その後に何がおきるはずだったか．
\end{enumerate}
レキシカル・スコープを持つLispでは，クロージャで第1の機能が得られる．
実はクロージャを使って計算処理の状態も変数束縛に格納すれば第2の機能も得られることが分かる．

\reffig{fig:ContPassMacro}のマクロを使うと，継続を保存しつつ関数を呼び出せる．
これらのマクロはCommon Lispで関数を定義したり呼び出したり，
値を返すための組込みオペレータの代わりになる．

継続を利用したい関数（もしくは継続を利用する関数を呼びたい関数）は
\verb|defun|でなく\verb|=defun|を使って定義する．
\verb|=defun|の構文は\verb|defun|と同じだが，機能は微妙に異なる．
単に関数を定義するだけでなく，\verb|=defun|は関数を定義し，
その関数の呼び出しに展開されるマクロを定義する．
（そのマクロは，関数が自分自身を呼び出す場合に備えて最初に定義しなければならない．）
関数の本体は\verb|=defun|に渡されたものになるが，引数リストには \verb|*cont*| が追加される．
マクロの展開形では，定義された関数は \verb|*cont*| を他の引数と一緒に受け取る．
よって次の関数定義は，
\begin{verbatim}
(=defun add1 (x) (=values (1+ x)))
\end{verbatim}
次のように展開される．
\begin{verbatim}
(progn (defmacro add1 (x)
         `(=add1 *cont* ,x))
       (defun =add1 (*cont* x)
         (=values (1+ x))))
\end{verbatim}

\verb|add1|を呼ぶとき実際に呼ばれるのは関数でなくマクロだ．
マクロは関数呼び出しに展開される
\footnote{\texttt{=defun}にはインターンされた名前が意図的に使われるが，
それはトレースできるようにするためだ．
トレースが必要でないと分かっていれば，名前にgensymを使うのが安全だろう．}
が，引数\,\verb|*cont*|\,を1つ余計に受け取っている．

よって \verb|=defun|で定義されたオペレータの呼び出しの際には，
その時点での \verb|*cont*| の値が必ず渡される．

\begin{figure}\begin{center}\begin{FramedVerb}
(setq *cont* #'identity)

(defmacro =lambda (parms &body body)
   `#'(lambda (*cont* ,@parms) ,@body))

(defmacro =defun (name parms &body body)
   (let ((f (intern (concatenate 'string
                                          "=" (symbol-name name)))))
       `(progn
            (defmacro ,name ,parms
               `(,',f *cont* ,,@parms))
            (defun ,f (*cont* ,@parms) ,@body))))

(defmacro =bind (parms expr &body body)
   `(let ((*cont* #'(lambda ,parms ,@body))) ,expr))

(defmacro =values (&rest retvals)
   `(funcall *cont* ,@retvals))

(defmacro =funcall (fn &rest args)
   `(funcall ,fn *cont* ,@args))

(defmacro =apply (fn &rest args)
   `(apply ,fn *cont* ,@args))
\end{FramedVerb}\end{center}
\caption{継続渡しマクロ．}
\label{fig:ContPassMacro}
\end{figure}

\verb|*cont*| は何のためにあるのか？\
それは現在の継続に束縛される．
\verb|=values|の定義を読むとその継続の使い方が分かる．
\verb|=defun|で定義された任意の関数は \verb|=values|を使って制御を戻すか，,
それを行う別の関数を呼ばなければいけない．
\verb|=values|の構文はCommon Lispの組込みオペレータ\verb|values|と同じだ．
多値を返すには，\verb|=bind|に同じ数の仮引数を与えておく．
しかしトップレベルに多値を返すことはできない．

仮引数 \verb|*cont*| は， \verb|=defun|で定義された関数に，返り値に対して何を行うかを伝える．
\verb|=values|がマクロ展開されると \verb|*cont*| を捕捉するようになり，
それによって関数から戻ることをシミュレートする．
次の式は，
\begin{verbatim}
> (=values (1+ n))
\end{verbatim}
次のように展開される．
\begin{verbatim}
(funcall *cont* (1+ n))
\end{verbatim}

トップレベルでは \verb|*cont*| の値は\verb|identity|だ．
これは渡された値をそのまま返す関数だ．
トップレベルから\verb|(add1 2)|を呼ぶと，それは等価な次のコードに展開される．
\begin{verbatim}
(funcall #'(lambda (*cont* n) (=values (1+ n))) *cont* 2)
\end{verbatim}

\verb|*cont*| の参照はこの場合グローバルな束縛を持つ．
\verb|=values|式は等価な次の式に展開される．
\begin{verbatim}
(funcall #'identity (1+ n))
\end{verbatim}
これは単に1から$n$までを足し合わせて返すものだ．

\verb|add1|などの関数では，
we go through all this trouble just to simulate what Lisp function call and return do anyway:
\begin{verbatim}
> (=defun bar (x)
        (=values (list 'a (add1 x))))
BAR
> (bar 5)
(A 6)
\end{verbatim}
大事なのは，今や私達は独自に制御できる関数呼び出しと戻りreturnを手にしており，
他のこともその気になればできるということだ．

継続の効果は， \verb|*cont*| を通じて利用する．
\verb|*cont*| はグローバルな値を持ってはいるが，グローバルな値そのものが使われることはまずない．
\verb|*cont*| はほとんど常に\verb|=values|や \verb|=defun|で定義されたマクロに捕捉される仮引数だ．
例えば\verb|add1|の内部では \verb|*cont*| は仮引数でグローバル変数ではない．
この区別が重要なのは，これらのマクロは \verb|*cont*| がローカル変数だからこそ機能するからだ．
だからこそ \verb|*cont*| に初期値を与えるために\verb|defvar|でなく\verb|setq|を使っている．
\verb|defvar|ではスペシャル変数を定義することになってしまう．

\reffig{fig:ContPassMacro}の3番目のマクロ \verb|=bind|は，
\verb|multiple-value-bind|と同様の用途を想定している．
引数には仮引数のリスト，式，実行部本体となるコードを取る．
仮引数は渡された式の返り値に束縛され，その下で本体コードが評価される．
\verb|=defun|で定義された関数の呼び出し後に付加的な式が評価されなければいけないときには
このマクロを使わなければいけない．
\begin{verbatim}
> (=defun message ()
          (=values 'hello 'there))
MESSAGE
> (=defun baz ()
          (=bind (m n) (message)
                 (=values (list m n))))
BAZ
> (baz)
(HELLO THERE)
\end{verbatim}

\verb|=bind|の展開形は新変数 \verb|*cont*| を作っていることに注意．
\verb|baz|の本体は次のようにマクロ展開される．
\begin{verbatim}
(let ((*cont* #'(lambda (m n)
                  (=values (list m n)))))
  (message))
\end{verbatim}
そしてさらに次のようになる．
\begin{verbatim}
(let ((*cont* #'(lambda (m n)
                  (funcall *cont* (list m n)))))
  (=message *cont*))
\end{verbatim}

\verb|*cont*| の新しい値は \verb|=bind|式の本体になるので，
\verb|*cont*| に\verb|funcall|を適用することで\verb|message|から「戻る」ときには，
結果は「コード本体を評価すること」になる．
しかし（ここが大事なのだが） \verb|=bind|の本体内では次のようになっており，
\begin{verbatim}
#'(lambda (m n)
    (funcall *cont* (list m n)))
\end{verbatim}
\verb|=baz|に引数として渡された \verb|*cont*| が見えるままなので，
コード本体が \verb|=values|を評価する番になると，
元の呼出側関数に戻ることができる．
クロージャは互いに縫い合わされている:
\verb|*cont*| の個々の束縛は \verb|*cont*| の以前の束縛を含むクロージャで，
グローバルな値に戻ってゆくまでの連鎖を形成する．

同じ現象を，もっと小さなスケールで観察できる．
\begin{verbatim}
> (let ((f #'identity))
    (let ((g #'(lambda (x) (funcall f (list 'a x)))))
      #'(lambda (x) (funcall g (list 'b x)))))
#<Interpreted-Function BF6326>
> (funcall * 2)
(A (B 2))
\end{verbatim}
この例では\verb|g|への参照を含むクロージャを作っているが，
\verb|g|そのものも\verb|f|への参照を含むクロージャである．
これと似たクロージャの連鎖が，xezページのネットワーク・コンパイラによって生成される．

残りのマクロ \verb|=apply|と \verb|=funcall|は \verb|=lambda|で定義された関数と共に使う．
\verb|=defun|で定義された「関数」は実際はマクロなので，
\verb|apply|や\verb|funcall|の引数に使えないことに注意．
この問題の解決策はldtページで触れたトリックに似ている．
つまり呼び出しを別の\verb|=lambda|の内部にくるんでしまう．
\begin{verbatim}
> (=defun add1 (x)
        (=values (1+ x)))
ADD1
> (let ((fn (=lambda (n) (add1 n))))
        (=bind (y) (=funcall fn 9)
           (format nil "9 + 1 = ~A" y)))
"9+1=10"
\end{verbatim}

\begin{enumerate}
\item \verb|=defun|で定義された関数の引数リストは仮引数名以外を含んではならない．
\item 継続を利用する関数，もしくはそのような関数を呼び出す関数は，
 \verb|=lambda|または \verb|=defun|で定義しなければならない．
\item そのような関数が終了するときは， \verb|=values|で値を返すか
    同様な関数を呼び出すかのいずれかでなければならない．
\item \verb|=bind|，\verb|=values|，\verb|=apply|または\verb|=funcall|が
    コードの一部に使われている場合，それは末尾呼び出しでなければならない．
    \verb|=bind|の後に評価されるべきコードは，必ずその本体内に入れなければならない．
    よって複数の\verb|=binds|を順に使いたい場合，それらは入れ子にならなければならない．
\end{enumerate}

\begin{figure}\begin{center}\begin{FramedVerb}
(=defun foo (x)
        (=bind (y) (bar x)
               (format t "Ho ")
               (=bind (z) (baz x)
                      (format t "Hum.")
                      (=values x y z))))
\end{FramedVerb}\end{center}
\caption{継続渡しマクロに付随する制限．}
\label{fig:RestrictionsContPassMacros}
\end{figure}

\reffig{fig:RestrictionsContPassMacros}には継続渡しマクロによって生じる制限をまとめた．
継続を保存しないし，継続を保存する関数を呼び出しもしない関数は，
これらのマクロを使う必要はない．
例えば\verb|list|などの組込み関数は除かれる．

\begin{figure}\begin{center}\begin{FramedVerb}
(defun dft (tree)
  (cond ((null tree) nil)
        ((atom tree) (princ tree))
        (t (dft (car tree))
           (dft (cdr tree)))))

(setq *saved* nil)

(=defun dft-node (tree)
        (cond ((null tree) (restart))
              ((atom tree) (=values tree))
              (t (push #'(lambda () (dft-node (cdr tree)))
                       *saved*)
                 (dft-node (car tree)))))

(=defun restart ()
        (if *saved*
            (funcall (pop *saved*))
            (=values 'done)))

(=defun dft2 (tree)
        (setq *saved* nil)
        (=bind (node) (dft-node tree)
               (cond ((eq node 'done) (=values nil))
                     (t (princ node)
                        (restart)))))
\end{FramedVerb}\end{center}
\caption{継続渡しマクロを使ったツリーの探索．}
\label{fig:TreeTraversalUsingContPassMacros}
\end{figure}

\reffig{fig:TreeTraversalUsingContPassMacros}は，
\reffig{fig:ContPassMacro}のSchemeコードをCommon Lispに直したものを含み，
継続渡しマクロをSchemeの継続の代わりに使っている．
同じ例のツリーに対して\verb|dft2|は全く同様に動作する．
\begin{verbatim}
> (setq t1 '(a (b (d h)) (c e (f i) g))
           t2 '(1 (2 (3 6 7) 4 5)))
(1 (2 (3 6 7) 4 5))
> (dft2 t1)
ABDHCEFIG
NIL
\end{verbatim}

複数の探索の状態を保存するのもSchemeと同様に機能するが，例は少し長くなる．
\begin{verbatim}
> (=bind (node1) (dft-node t1)
        (if (eq node1 'done)
             'done
             (=bind (node2) (dft-node t2)
               (list node1 node2))))
(A 1)
> (restart)
(A 2)
...> (restart)
(B 1)
...
\end{verbatim}

レキシカル・クロージャの連鎖をつなぎ合わせることで，
Common Lispプログラムでも独自の継続を作ることができる．
うまいことに，
\reffig{fig:ContPassMacro}の込み入ったマクロによってクロージャはつなぎ合わされており，
ユーザは実現過程を想像する必要はなく，きれいな側面だけを見ていればよい．

第21--24章はいずれもある意味で継続に依存している．
これらの章では，継続がすさまじい力の抽象化であることを示す．
継続は，特にあるプログラミング言語上のマクロとして実装された場合には，最高に速いとは言えない．
しかしそれらを利用して行える抽象化により，ある種のプログラムははるかに速く書けるようになり，
そのような速度のプログラムも重宝する場合というものはある．
%}}}
\subsection{Code-Walkers と CPS変換}   %{{{
前節で説明したマクロは妥協の産物だ．
継続の力が得られるが，それはプログラムを特定の形で書いたときに限られる．
\reffig{fig:RestrictionsContPassMacros}のルール4によれば，必ず次のようにしなければならず，
\begin{verbatim}
(=bind (x) (fn y)
       (list 'a x))
\end{verbatim}
次のようにはできない．
\begin{verbatim}
(list 'a                                                        ; wrong
      (=bind (x) (fn y) x))
\end{verbatim}

本物の\verb|call/cc|はプログラマにそのような制限を課すことはない．
\verb|call/cc|は任意の時点で任意の形のプログラムの継続を取り出せる．
\verb|call/cc|の力の全てを実現するオペレータを実装することもできるが，
それにはさらに手間がかかるだろう．
この節ではその方法の概要を示す．

Lispプログラムは「継続渡しスタイル」という形に変換できる．
完全にCPS変換を施したプログラムは読めたものではないが，
部分的に変換されたコードを読むことでその過程のエッセンスを掴むことはできる．
次の関数はリストを逆転させるものだが，
\begin{verbatim}
(defun rev (x)
  (if (null x)
      nil
      (append (rev (cdr x)) (list (car x)))))
\end{verbatim}
等価な継続渡し版コードは次のようになる．
\begin{verbatim}
(defun rev2 (x)
  (revc x #'identity))

(defun revc (x k)
  (if (null x)
      (funcall k nil)
      (revc (cdr x)
            #'(lambda (w)
                (funcall k (append w (list (car x))))))))
\end{verbatim}
継続渡しスタイルでは，
関数には引数（ここでは\verb|k|）が余分に増える．
その値は継続になる．
継続は，その関数の現在の値を使って何をすべきかを表現するクロージャだ．
再帰の最初の段階では継続は恒等関数だ．
何をすべきかと言えば，関数は現在の値をそのまま返せばよい．
再帰の第2段階では，継続は次と等価だ．
\begin{verbatim}
#'(lambda (w)
        (identity (append w (list (car x)))))
\end{verbatim}
つまり，何をするべきかと言えば，リストのcar部を現在の値に付加して返すということだ．

CPS変換を覚えれば\verb|call/cc|を書くのは簡単だ．
CPS変換を経たプログラムでは，全体に対する現在の継続が常に存在し，
\verb|call/cc|はその引数として何らかの関数を呼び出す単純なマクロとして実装できる．

CPS変換には，code-walker,
すなわちプログラムのソースコードを表現するツリーを探索するプログラムが必要になる．
Common Lispに対するcode-walkerを書くのはひどい骨折りだ．
使えるものになるには，code-walkerは単に式を探索するだけでは済まず，．
その式の意味もかなり理解できなければならない．
例えば，code-walkerはシンボルだけを考えていれば済むものではない．
シンボルが表現するのは，いくつか挙げると，
シンボル自身，関数，変数，ブロック名，\verb|go|のためのタグなどだ．
Code-walkerは文脈からシンボルの種類を判別し，それに従って動作しなければならない．

Code-walkerを書くのはこの本の範囲を超えるので，この章で説明したマクロは実用的な代理品に過ぎない．
この章のマクロは継続を構築する仕事をユーザと分担して行う．
ユーザがCPSに十分近いプログラムを書けば，残りはマクロがやってくれる．
第4の規則は本当はそういうことだ．
\verb|=bind|の後に続く処理がその本体内にあれば，
\verb|*cont*| の値と \verb|=bind|の本体内のコードの間で，
プログラムは現在の継続を作るための十分な情報を得ることができる．

マクロ \verb|=bind|はこのスタイルのプログラミングを自然に思わせる意図を持って書かれた．
実際には継続渡しマクロの課す制限は我慢の範囲内だろう．
%}}}
%}}}
\section{複数プロセス} %{{{
前章では，継続を利用すれば実行中のプログラムが自分の状態を把握し，
それを保存して後で再開することができることを示した．
この章で扱う計算処理のモデルは，
計算機が単一のプログラムを実行するのでなく，独立したプロセスの集合を実行するというものだ．
プロセスの概念はプログラムの状態という概念と深い対応関係にある．
前章で示したマクロの上にさらにもう一層のマクロを書くことで，
Common Lispプログラムの中に複数プロセスを埋め込むことができる．
\subsection{プロセスの抽象化}   %{{{
複数プロセスは，複数の処理を同時に行わなければならないプログラムを表現するのに便利だ．
伝統的なCPUはインストラクションを1つずつ実行する．
「複数プロセスは同時に複数の処理を行う」というのは，
このハードウェア上の制限をどうにか乗り越えるという意味ではない．
それを使って，抽象化の新たな段階でものを考えられるようになるということだ．
つまりコンピュータがある時点で何を行うか，逐一指定しなくともよい．
仮想メモリによって，コンピュータが実際に備えているより多くのメモリがあるかのように思えるのと同様，
プロセスの概念によって，コンピュータが同時に複数のプログラムを実行できるかのように思っていられる．

プロセスの研究は伝統的にはOSの分野で行われていた．
しかし抽象化の観点としてのプロセスの利便性はOSの世界に限られてはいない．
プロセスは他のリアルタイムアプリケーションやシミュレーションでも同様に便利なものだ．

複数プロセスに基づいてなされた仕事の大部分は，ある種の問題の回避に費されてきた．
デッドロックは複数プロセスに伴う古典的問題の一つだ．
すなわち，相手より先に敷居を越えるのを互いに拒む2人の人のように，
2つのプロセスが何もせずに，共にもう片方が何かを行うのを待ち続けることだ．
他にも，一貫していない状態にあるシステムに対するクエリの問題もある．
例えば，システムが預金をある口座から別の口座に移している最中に残高が問い合わせられる場合だ．
この章で扱うのはプロセスによる抽象化のみだ．
ここで示されたコードは，
デッドロックや一貫していない状態を防ぐアルゴリズムのテストに使えるかもしれないが，
コードそのものはそれらの問題に対する防御措置を一切取っていない．

この章における実装は，この本の全てのプログラムが暗黙に従っている規則に従っている．
すなわち「なるだけLispとぶつかるな」だ．
気持ちとしては，プログラムはできる限りプログラミング言語の修正に近付くべきで，
そのプログラミング言語で書かれた個別のアプリケーションになるべきではない．
プログラムをLispと調和するように作れば，ぴったり合った部品で作られた機械のように頑健になる．
また，労力の節約にもなる．
驚く程の量の処理をLispに肩代りさせられることもある．

この章の目的は，複数プロセスに対応したプログラミング言語を作ることだ．
ここでの戦略は，新オペレータをいくつか追加して，Lispをそのようなものに変えてゆくことだ．
新プログラミング言語の基本要素は次のようなものだ．

関数は，前章のマクロ\,\verb|=defun|や\,\verb|=lambda|で定義される．

プロセスは関数呼び出しによって生成される．
（一つの関数から生成されていても）アクティブなプロセスの数に制限はない．
各プロセスには優先度が定まっており，その初期値はプロセスを生成するときの引数で与えられる．

\verb|wait|式を関数内で使うことができる．
\verb|wait|式は，変数とテスト式と，実行本体となるコードを引数に取る．
プロセスが\verb|wait|式に出会うと，テスト式が真を返すまでその時点で処理が中断される．
プロセスが再始動すると，
\verb|wait|式に与えた変数がテスト式の返り値に束縛された状態でコード本体が評価される．
テスト式は普通は副作用を持つべきではない．
いつ，どの位の頻度で評価が行われるかの保証がないからだ．

スケジューリングは優先度に基づいて行われる．
再始動し得る全てのプロセスのうち，最高の優先度を持つプロセスをシステムが選んで始動させる．

他に始動するプロセスがないときにはデフォルト・プロセスが始動する．
それはread-eval-printループの一種だ．

大抵のオブジェクトは実行中に生成や破棄ができる．
実行中のプロセスで新しい関数を定義することもできるし，
別のプロセスを始動したり終了させたりもできる．

継続により，Lispプログラムの状態を保持することができる．
複数の状態を同時に保持していられることは，複数のプロセスがあることと大して違わない．
複数プロセスを実装するには，前章で定義したマクロから始めて60行弱のコードしか必要ない．
%}}}
\subsection{実装}   %{{{
\begin{figure}\begin{center}\begin{FramedVerb}
(defstruct proc pri state wait)

(proclaim '(special *procs* *proc*))

(defvar *halt* (gensym))

(defvar *default-proc*
  (make-proc :state #'(lambda (x)
                        (format t "~%>> ")
                        (princ (eval (read)))
                        (pick-process))))

(defmacro fork (expr pri)
  `(prog1 ',expr
     (push (make-proc
             :state #'(lambda (,(gensym))
                        ,expr
                        (pick-process))
             :pri      ,pri)
           *procs*)))

(defmacro program (name args &body body)
  `(=defun ,name ,args
           (setq *procs* nil)
           ,@body
           (catch *halt* (loop (pick-process)))))
\end{FramedVerb}\end{center}
\caption{プロセス構造体とその生成．}
\label{fig:ProcessStructInstantiation}
\end{figure}

\begin{figure}\begin{center}\begin{FramedVerb}
 (defun pick-process ()
       (multiple-value-bind (p val) (most-urgent-process)
        (setq *proc* p
                  *procs* (delete p *procs*))
        (funcall (proc-state p) val)))

 (defun most-urgent-process ()
       (let ((proc1 *default-proc*) (max -1) (val1 t))
        (dolist (p *procs*)
          (let ((pri (proc-pri p)))
             (if (> pri max)
                   (let ((val (or (not (proc-wait p))
                                      (funcall (proc-wait p)))))
                     (when val
                       (setq proc1 p
                               max     pri
                               val1 val))))))
        (values proc1 val1)))

 (defun arbitrator (test cont)
       (setf (proc-state *proc*) cont
             (proc-wait *proc*) test)
       (push *proc* *procs*)
       (pick-process))

 (defmacro wait (parm test &body body)
       `(arbitrator #'(lambda () ,test)
                      #'(lambda (,parm) ,@body)))

 (defmacro yield (&body body)
       `(arbitrator nil #'(lambda (,(gensym)) ,@body)))

 (defun setpri (n) (setf (proc-pri *proc*) n))

 (defun halt (&optional val) (throw *halt* val))

 (defun kill (&optional obj &rest args)
       (if obj
          (setq *procs* (apply #'delete obj *procs* args))
          (pick-process)))
\end{FramedVerb}\end{center}
\caption{プロセスのスケジューリング．}
\label{fig:ProcessScheduling}
\end{figure}

\reffig{fig:ProcessStructInstantiation}と\reffig{fig:ProcessScheduling}には，
複数プロセスに対応するために必要な全てのコードを示した．
\reffig{fig:ProcessStructInstantiation}のコードは，基本的データ構造，デフォルト・プロセス，
プロセスの初期化や生成のためのものだ．
プロセスすなわち\verb|procs|は以下の構造を持つ．
\begin{description}
    \item[pri]はプロセスの優先度で，正の整数．
    \item[state]は中断されたプロセスの状態を表す継続．
        プロセスの再始動は，この状態を\verb|funcall|に渡すことで行われる．
    \item[wait]は関数で，これが真を返さないとプロセスは再始動できない．
        しかし新たに生成されたばかりのプロセスでは\verb|nil|になっている．
        \verb|wait|が\verb|nil|のプロセスは常に再始動できる．
\end{description}

プログラムは3つのグローバル変数を使う．
\verb|*procs*|は中断中のプロセスのリスト，\verb|*proc*|は実行中のプロセス，
\verb|*default-proc*|はデフォルト・プロセスを格納する．

デフォルト・プロセスが実行されるのは，他に実行できるプロセスがないときだ．
ちょうどLispのトップレベル環境に似せている．
ユーザはこのループ内で，
プログラムを停止させたり，中断中のプロセスを再始動させられる式を入力したりできる．
デフォルト・プロセスは\verb|eval|を陽に呼んでいることに注意．
ここはそうすることが理に適う数少ない状況の一つだ．
一般に，実行時に\verb|eval|を呼ぶのはよい考えではない．
その理由は以下の2つだ．
\begin{description}
    \item[効率が悪い]
        \verb|eval|は生のリストを渡されるが，
        それをその場でコンパイルなりインタプリタを使って評価なりせざるを得ない．
        どちらにせよ，コードを予めコンパイルしておいて呼び出すだけのときより遅くなる．
    \item[表現力が低い]
        式がレキシカル・コンテキストなしで評価されるからだ．
        とりわけ，評価される式の外側で見えている普通の変数にアクセスできない．
\end{description}

普通，\verb|eval|を陽に呼ぶことは空港の土産物屋で買いものをするようなものだ．
延々と待たされたあげく，品揃えの悪い，それも二流品ばかりの店に高い金を支払うことになる．

今の状況は上の議論がどちらも当てはまらない稀な例だ．
ここでは式を予めコンパイルすることはあり得ない．
その時点で読み込んでいるのだから，予めなどというものはない．
同様に，式はそれを包むレキシカル環境を元々参照できない．
トップレベルに入力された式はヌル・レキシカル環境の中にあるからだ．
実際，この関数の定義は「ユーザが入力したものを読み込んで評価する」をそのまま反映している．

マクロ\verb|fork|は関数呼び出しによってプロセスを生成する．
関数は\,\verb|=defun|によって通常通り定義できる．
\begin{verbatim}
(=defun foo (x)
  (format t "Foo was called with ~A.~%" x)
  (=values (1+ x)))
\end{verbatim}
さて関数呼び出しと優先度を引数に\verb|fork|を呼び出すと，
\begin{verbatim}
(fork (foo 2) 25)
\end{verbatim}
新しいプロセスが\,\verb|*procs*|\,にプッシュされる．
その新プロセスは優先度が25で，
（\verb|proc|の）\verb|wait|フィールドが\verb|nil|（まだ始動させられていないため），
\verb|state|フィールドが2を引数とした\verb|foo|の呼び出しになっている．

マクロ\verb|program|によって，一群のプロセスを生成し，一緒に実行できる．
次の定義は，2つの\verb|fork|式が，
中断されたプロセスを消去するコードと実行するプロセスを繰り返し選ぶコードに
挟まれたものにマクロ展開される．
\begin{verbatim}
(program two-foos (a b)
  (fork (foo a) 99)
  (fork (foo b) 99))
\end{verbatim}
このループの外側ではマクロがタグを設定しており，そこに制御を移すことでプログラムを終了できる．
このタグはgensymなので，ユーザのコードが設定したタグと衝突しない．
\verb|program|で定義されたプロセスたちは特に値を返さず，
トップレベルから呼ばれることのみを意図している．

プロセスが生成された後，
\reffig{fig:ProcessScheduling}に示したプロセスのスケジューリング用のコードが入れ替わりに起動する．
関数\verb|pick-process|は，再始動可能なプロセスのうち優先度が一番高いものを選んで始動させる．
そのプロセスを選ぶのは\verb|most-urgent-process|の仕事だ．
停止中のプロセスが始動できるのは，\verb|wait|式が中にないか，
または\verb|wait|式が真を返したときだ．
始動可能なプロセスのうちで最も優先度が高いものが選ばれる．
選ばれたプロセスと，その中に\verb|wait|式があればその返り値が\verb|pick-process|に渡される．
デフォルト・プロセスが常に始動しようとしているので，必ずいずれかのプロセスが選ばれることになる．

\begin{figure}\begin{center}\begin{FramedVerb}
(defvar *open-doors* nil)

(=defun pedestrian ()
  (wait d (car *open-doors*)
    (format t "Entering ~A~%" d)))

(program ped ()
  (fork (pedestrian) 1))
\end{FramedVerb}\end{center}
\caption{\texttt{wait}式1つを持つプロセス．}
\label{fig:OneProcessOneWait}
\end{figure}

\reffig{fig:ProcessScheduling}の残りのコードは
プロセス間で制御を切替えるためのオペレータを定義している．
待機するための標準的な式は\verb|wait|で，
\reffig{fig:ProcessScheduling}内の関数\verb|pedestrian|でも使われている．
この例では，プロセスはリスト\,\verb|*open-doors*|\,に要素が含まれない間は待機し，
要素があるときはメッセージを表示する．
\begin{verbatim}
> (ped)
>> (push 'door2 *open-doors*)
Entering DOOR2
>> (halt)
NIL
\end{verbatim}

\begin{figure}\begin{center}\begin{FramedVerb}
(defvar *bboard* nil)

(defun claim   (&rest f) (push f *bboard*))

(defun unclaim (&rest f) (pull f *bboard* :test #'equal))

(defun check   (&rest f) (find f *bboard* :test #'equal))

(=defun visitor (door)
  (format t "Approach ~A. " door)
  (claim 'knock door)
  (wait d (check 'open door)
    (format t "Enter ~A. " door)
    (unclaim 'knock door)
    (claim 'inside door)))

(=defun host (door)
  (wait k (check 'knock door)
    (format t "Open ~A. " door)
    (claim 'open door)
    (wait g (check 'inside door)
      (format t "Close ~A.~%" door)
      (unclaim 'open door))))

(program ballet ()
  (fork (visitor 'door1) 1)
  (fork (host 'door1) 1)
  (fork (visitor 'door2) 1)
  (fork (host 'door2) 1))
\end{FramedVerb}\end{center}
\caption{黒板を使った同期．}
\label{fig:SynchroWithBlackboard}
\end{figure}

\verb|wait|は\,\verb|=bind|（xgoページ）に似ており，
それと同様に，最後に評価されなければならないという制限を持つ．
\verb|wait|の後に行いたい処理は，全てその中に入れなければならない．
よって\verb|wait|を複数回使いたければ，\verb|wait|式はネストさせなければならない．
互いを考慮した事実を仮定することで，
プロセスは\reffig{fig:SynchroWithBlackboard}のようにゴールに到達するための共同作業が行える．

\verb|visitor|と\verb|host|により生成されたプロセスは，
同じドアを与えられたとき，黒板上のメッセージを通じて制御をやりとりする．
\begin{verbatim}
> (ballet)
Approach DOOR2. Open DOOR2. Enter DOOR2. Close DOOR2.
Approach DOOR1. Open DOOR1. Enter DOOR1. Close DOOR1.
>>
\end{verbatim}

他に\verb|wait|式の単純なものがある．
\verb|yield|の目的は，他の優先度の高いプロセスに始動を機会を譲ることだけだ．
プロセスは式\verb|setpri|（これはカレント・プロセスの優先度を再設定する）の実行後に
\verb|yield|を実行するとよいかもしれない．
\verb|wait|と同様に，
\verb|yield|の後に実行したいコードは全てその内部に入れなければならない．

\begin{figure}\begin{center}\begin{FramedVerb}
(wait d (car *bboard*) (=values d))

(=defun capture (city)
  (take city)
  (setpri 1)
  (yield
    (fortify city)))

(=defun plunder (city)
  (loot city)
  (ransom city))

(defun take    (c) (format t "Liberating ~A.~%" c))
(defun fortify (c) (format t "Rebuilding ~A.~%" c))
(defun loot    (c) (format t "Nationalizing ~A.~%" c))
(defun ransom  (c) (format t "Refinancing ~A.~%" c))

(program barbarians ()
  (fork (capture 'rome) 100)
  (fork (plunder 'rome) 98))
\end{FramedVerb}\end{center}
\caption{優先度の変更の効果．}
\label{fig:EffectOfChangingPriority}
\end{figure}

\reffig{fig:EffectOfChangingPriority}のプログラムでは，
これらのオペレータがどのように協調して動作するかを示した．
（訳注： captureは「捕らえる」，plunderは「略奪する」，takeは「取る」，
liberateは「（支配から解き放って）自由にする」，
fortifyは「要塞化する」，lootは「略奪する」，ransomは「身代金を要求する」，
refinanceは「財務を再構築する」という程の意味．）
最初，蛮族 (barbarians) には2つの目的がある．
ローマの制圧とそこでの略奪だ．
ローマの制圧の方が（わずかに）優先度が高いので，そちらが先に実行される．
しかしローマが制圧された後は，プロセス\verb|capture|の優先度は1に下がる．
そこでプロセス選択が行われ，その結果，優先度が最大のプロセス\verb|plunder|が始動する．
\begin{verbatim}
> (barbarians)
Liberating ROME.
Nationalizing ROME.
Refinancing ROME.
Rebuilding ROME.
>>
\end{verbatim}
蛮族がローマの宮殿で略奪を行い，貴族の身代金を奪った後にのみプロセス\verb|capture|は停止し，
蛮族は拠点の要塞化に移る．

基盤となっている式\verb|wait|は，\verb|arbitrator|を一般化したものだ．
この関数はカレント・プロセスを保存し，
\verb|pick-process|を呼んで，何らかのプロセス（大抵は同じもの）を始動させる．
これは2つの引数，テスト式と継続を取る．
テスト式は停止中のプロセスの\verb|proc-wait|として保持され，
それを再始動するかどうか決定するために後で呼び出される．
継続は\verb|proc-state|に保持されるが，
これを呼び出すと停止しているプロセスが再始動することになる．

マクロ\verb|wait|と\verb|yield|はその継続関数を生成するが，
やっていることは単にその本体を$\lambda$式で包むことだけだ．
例えば，
\begin{verbatim}
(wait d (car *bboard*) (=values d))
\end{verbatim}
は
\begin{verbatim}
(arbitrator #'(lambda () (car *bboard*))
  #'(lambda (d) (=values d)))
\end{verbatim}
に展開される．

コードが\reffig{fig:RestrictionsContPassMacros}の制限を満たしていれば，
\verb|wait|本体のクロージャを生成するとき，現在の継続全体が保存される．
第2引数の\verb|=values|が展開されると，次のようになる．
\begin{verbatim}
#'(lambda (d) (funcall *cont* d))
\end{verbatim}
クロージャが\verb|*cont*|への参照を含むため，
関数\verb|wait|で停止させられたプロセスは，停止した時点ではどこに置かれていたか，
という目印を持つことになる．

オペレータ\verb|halt|は，
制御をプログラムの展開形が設定したタグに移すことでプログラム全体を停止させる．
オプショナル引数にはプログラム全体の値として返すための値を渡せる．
デフォルト・プロセスが常に始動しようとしているので，
プログラムの終了には明示的に\verb|halt|を呼ぶしかない．
\verb|halt|の後にどのようなコードが続いても，評価されることがないので意味がない．

各プロセスは式\verb|kill|を呼ぶことで終了させられる．
引数無しでこれを呼ぶと現在実行中のプロセスが終了させられる．
その場合，\verb|kill|はカレント・プロセスの状態を保持しない\verb|wait|の一種のようなものだ．
\verb|kill|に渡した引数は，プロセスのリストから削除するものを指定する．
現状のプログラムでは参照すべきプロセスの属性が多くないので，
\verb|kill|について説明することは大してない．
しかしもっと手の込んだシステムでは，
他にタイムスタンプ，オーナ等の情報をプロセスに関連づけることになるだろう．
デフォルト・プロセスはリスト\,\verb|*procs*|\,に含まれていないので，\verb|kill|を適用できない．
%}}}
\subsection{「早い」だけではないプロトタイプ}   %{{{
継続を使って模倣したプロセスには，本物のOSのプロセス程の効率は望めない．
ならば，この章で示したプログラムの用途は一体何だろう？

それらの便利さは，ちょうどスケッチと同じだ．
実験的なプログラミングやラピッド・プロトタイピングでは，
プログラムはそれ自身で完成品なのではなく，むしろ考えを展開させるための乗り物だ．
他の多くの領域では，この目的に使われるものはスケッチと呼ばれる．
建築家は，原則的には，建物全体を頭の中で創り上げることができる．
しかし，ほとんどの建築家は鉛筆を手にしていた方が考えが進むようだ．
普通、建物のデザインは手始めにスケッチを何枚か描く中で考える．

ラピッド・プロトタイピングはソフトウェアのスケッチだ．
建築家の下描きのように，ソフトウェアのプロトタイプは軽々としたタッチで描かれることが多い．
アイディアを形にする最初期の一歩では，費用と効率の考慮は無視される．
この段階での結果は，建築不可能な建物や，救いようもなく非効率的なソフトウェアになりがちだ．
それであってもスケッチの価値は変わらない．
なぜなら
\begin{enumerate}
    \item 情報を簡潔に運ぶ入れ物であり，
    \item 実験する機会を与える
\end{enumerate}
からだ．

この章で説明したプログラムは，その前の章のプログラムと同様，スケッチであり，
複数プロセスの概要を大雑把な筆遣いで提示している．
商用ソフトウェアで使える程効率的ではないだろうが，
複数プロセスの他の側面を使って，スケジューリングのアルゴリズムなどを実験するにはとても便利だ．

第22--24章では，継続の他の応用を示す．
いずれも商用ソフトウェアで使える程効率のよいものではない．
Lispとラピッドプロトタイピングは共に発展してきたので，
Lispには特にプロトタイプを意図した，
属性リスト，キーワード引数，そしてリストといった非効率的だが便利な機能が沢山備わっている．
継続も恐らくこの仲間に入る．
継続はプログラムが必要にするより多くの状態を保存する．
だから，例えば後で出てくる継続ベースで実装されたPrologは，
そのプログラミング言語を理解する方法としてはよいが，実装方法としては非効率的だ．

この本が重視するのはLispで実現できる抽象化であって，効率性に関わる話題ではない．
しかし，Lispはプロトタイプを書くための言語であるばかりでなく，
商用ソフトウェアを書くための言語でもあるということを認識しておくことは重要だ．
「Lispは遅い」との評判があるとすれば，
それは多分に多くのプログラマがプロトタイプで止まってしまったせいだ．
Lispでは速いプログラムを簡単に書けるが，残念なことに，遅いプログラムも簡単に書ける．
Lispプログラムの初期版はダイアモンドのようなものだ．
小さく，透き通っていて，そして非常に高価だ．
それをそのままにしておきたいという欲求は大きいかもしれない．

他のプログラミング言語では，書いたプログラムを動作させるという骨の折れる課題に成功しさえすれば，
その効率性はすでに許容可能なものだろう．
床にタイルを敷くとき，タイルが爪程の大きさだったら，無駄になるタイルも少ない．
この考えに基づいてプログラムを開発していた人には，
「プログラムが動作したらそこで開発は完了する」という考えを乗り越えるのは難しいかもしれない．
「Lispを使うとプログラムが手間要らずで書ける．
ああ，しかしそうすると遅いんだ．」と彼は思うかもしれない．
実際は，どちらも当てはまらない．
速いプログラムは実現できるし，しかしそれには手間をかけなければならない．
この点では，Lispを使うのは，貧しい国でなく豊かな国に暮らすようなものだ．
痩せた体型を維持するために働かなければならないのは困ったことかもしれないが，
命をつなぐために働いており，太ることなど問題外，という状況よりはずっとよい．

抽象度の低いプログラミング言語では，機能を求めて開発することになる．
Lispでは，速度を求めて開発することになる．
幸運なことに，速度を求めて開発する方が容易だ．
大抵のプログラムでは，スピードに深刻に影響する部分は数か所しかない．
%}}}
%}}}
\section{非決定性} %{{{
プログラミング言語を使うことで，膨大な量の詳細に飲み込まれないで済んでいる．
Lispがよいプログラミング言語なのは，それ自身が多くの詳細を扱ってくれて，
プログラマが耐えられる複雑さの限界を有効に使わせてくれている．
この章ではマクロでLispにさらに別の種類の詳細を扱わせる方法を示す．
非決定的なアルゴリズムを決定的なものに変換することの詳細だ．

この章は5つの部分に分けられる．
まず，非決定性とは何かを説明する．
次に，非決定的な\emph{choose}と\emph{fail}を継続を使ってSchemeで実装する．
3番目では，第20章の継続渡しマクロを基礎にCommon Lispで実装した\emph{choose}と\emph{fail}を示す．
4番目では，オペレータ\emph{cut}をPrologとは独立に理解する方法を示す．
最後に，非決定的オペレータの改良について考察する．

この章で定義される非決定的な選択オペレータは，
第23章のATNコンパイラと第24章の埋め込みPrologを実装するのに使われる．
\subsection{概念}   %{{{
非決定的アルゴリズムはある意味では超自然的な予見に基づいて動作するものだ．
超能力を持ったコンピュータに触れることのない私達に，どうしてそんなものが必要なのだろうか？\ 
それは非決定的アルゴリズムを決定的アルゴリズムでシミュレートできるからだ．
純粋に関数的なプログラム\wadash すなわち副作用の一切ないもの\wadash では，
非決定性は特に直截的になる．
純粋に関数的なプログラムでは非決定性はバックトラックを用いた探索で実現できる�