『n月刊ラムダノート Vol.1, No.2』を読むべき1つめの理由

『n月刊ラムダノート』の話をいろいろしたいのだけど、どこから話せばいいのかわからないので、Lispの話をします。

昔、といってもほんの10年ちょっと前のことですが、日本でLispが流行った時期がありました。「プログラミング言語のパワーには絶対的な差が存在する。その頂点に立つのがLispだ」と言って憚らない『ハッカーと画家』という本が2005年に出版され、それを読んだ多くの人が「よろしい、ならばLispだ」と思ったのです。

まあ、ほかにもいろいろな理由があったのだろうし、流行に関係なくLispを使い続けている人はたくさんいたし、いまでもぼくを含め多くの人がLispを日常的に使っているけれど、『ハッカーと画家』の影響によるちょっとしたLispブーム、というのは確かに起きていたと思います。

で、この『ハッカーと画家』を翻訳したのが川合史朗さんでした。その当時、ぼくは同書を企画した部署にたまたまいて、その制作の様子をちょっと横で見てたりもしたんですが、川合さんはハワイ在住ということもあって面識があるわけでもなく、同書の訳者としての川合さんは実はよく知りません。

ぼくにとって川合さんは、むしろGaucheの作者としての川合さんです。 Gaucheというのは、Lispの二大巨頭のひとつであるSchemeの実装です。LispとかSchemeとかを抜きにしても、日本語の処理が楽にできた高機能なスクリプト言語でした。すべてがUTF-8になった現在、たいていの言語で日本語の扱いに難儀することはあまりないですが、そのころは日本語に対して何も考えずに正規表現を使えるというだけでGaucheは魅力的なプログラミング環境だったのです。もちろんPerlやRubyはあり、それらを仕事や趣味に使ってはいたんですが、Gaucheの存在を知って使ってみたところ、「S式はいろいろ快適」という事実を思い知ったのでした。

「S式はいろいろ快適」には、もうすこし補足が必要かもしれない。

ぼくの仕事は書籍の編集者なんですが、書籍の編集者というのはXMLをよく扱います。 XMLの構造を扱うのに、ふつうはXSLTというプログラミング言語を使うのですが、ぼくはこれがあまり好きじゃなかった。 XMLは、要するに木構造なので、そのままS式に見えるし、それならS式として扱いたいわけです。実際、XMLのS式表現として、SXMLというものがあります。ありがたいことに、GaucheにはSXMLのためのツール群もまるっと用意されていました。

というわけで、ぼくが日常的に使うプログラミング言語はもっぱらGaucheという状態になり、自然とGaucheを中心としたコミュニティにもどきどき顔を出すようになったりしました。Gauche Nightで発表したのは本当に素晴らしい思い出です。 Gaucheのコミュニティは、そのまま他のLisp系言語のコミュニティや関数型言語、特にHaskellのコミュニティなんかとも地続きで、結果として本当にたくさんのすごい人たちに出会うことができました。

いまも、大半のやっつけスクリプトにはGaucheを使います。そこそこ大きめのプログラムを書くときはHaskellを使うし、ぶっちゃけXMLをいじるのもS式よりArrowのほうが脳が楽なことに気が付いたけれど、それでもプログラムを考えるときは脳内でまずS式をこねこねする癖は抜けないので、自分にとっての母国語は完全にLispであり、Schemeであり、Gaucheであり、その生みの親かつ育ての親こそが川合さんなわけです。

その川合さんが、Lispの記事を、自分がやってる出版社の逐次刊行物で書いてくれました。やったね！

n月刊ラムダノート Vol.1, No.2(2019)（紙書籍＋PDF版）www.lambdanote.com

f:id:golden-lucky:20190726123033j:plain

しかも、まさかの「LISP 1.5」です。

Lispは、プログラミング言語としては歴史が古いので、現代的なコンピューターでプログラミングしているとあまり意識しなくて済むような概念や、いまでは別の考え方で把握され解決されているような困難にまつわる話がわりとちょくちょく出てきます。そうした古の概念であるとか、過去の偉人たちが困難に対峙してきた物語もまた、Lispの魅力のひとつだったりします。

歴史の話、楽しいじゃないですか。 いまぼくらが入門書とか教科書という形で整理された内容を学べるのは素敵なことだけど、なぜ教科書にあるような形で内容が整理されており、それをぼくらが学ぶ必要があるのか、根っこを知ってはじめて見えてくる景色もあるわけです。

そう考えると、Lispのパワーっていうのは、そうやって理論と実践の縁をいったり来たりしながら、後代のプログラマーたちが発見することを別の形ですでに体得しちゃってるかもしれない側面なのかもしれない。エモい話になりそうなのでこの辺でやめますが、そんなわけで、Lispをちょっとでもかんじると、今のプログラミングにおいて当たり前だったり、理論的には別の手段で解消されたりしている昔の話に、わりとよくぶつかります。

ここで、ぼくのようなLispと同時代を生きてきていない素人にとって辛いのが、そういうときに自力で原典に立ち返ろうと思っても話の文脈がいまいちよく見えないことです。論文などに書いてある記述を素直に読み、文脈を補完する努力をすればいいのだけど、そこまでの余裕がなかったりするので、「話だけは聞いたことある」みたいなキーワードだけが脳内に積まれていきます。「LISP 1.5」は、そんな「話だけは聞いたことある」というLispなキーワードのなかでも、かなり上位にあるやつでした。（勝手な想像ですが、ぼくみたいな「ゆるふわLisper」はほかにもわりと多いような気がします。）

Lispをやっていないとわからないかもなんですが、「LISP 1.5」、Lisperをやっていると、本当に名前だけは耳にするんです。そもそもLispを発明したのはジョン・マッカーシーで、彼は人工知能研究の一環としてリスト処理のための言語を考案したけど、最初は計算機で動かすプログラミング言語を考えているつもりはなかったらしい。これをスティーブ・ラッセルが計算機上で実行できるように実装し、それを改良していろいろがんばったのが「LISP 1.5」だったらしい。「らしい」ばかりなのは、ほんとよく耳にするけど少なくともぼくにとって「LISP 1.5」は文字通り「伝説」の存在だったからです。

ちょっと話はそれますが、Schemerをやっていても、やはり似たような感覚におそわれるキーワードがあります。そのひとつは、「funarg問題」っていうやつです。 funargは、「function」と「argument」の造語なんですが、たぶん「ふなーぐ」と読みます。これは要するに、関数の引数に関数を渡すと仮引数が衝突してしまうという話で、 Schemeはこの「funarg問題」を根本的に解消したLispであるという触れ込みがあることから、Schemeを勉強すると必ずといっていいほど目にすることになります。しかし、プログラミング言語の教科書だと束縛変数の名前を暗に付け替えることで回避してるし、関数プログラミングをしていても実際にハマることはほとんどないので、なんでSchemeがそこまで「funarg問題に煩わされない」ことを喧伝しているのかピンとこない。

さらに話はそれますが、プログラミング言語を独習したり人に教えたりしてると、「シンボル」が何なのかわからなくならないですか？文字列みたいに使えるけど書き換え不能なやつ、みたいな理解でいいと思うんですが、これ、言語の処理系ではどうやって実現されてるんでしょうか。いま、何か言語を作るなら、ルックアップテーブルを使ってシンボルを実現すると思います。しかし、コンピューター上でシンボルを表現する方法はほかにないんでしょうか。

川合さんによる『LISP 1.5の風景』は、ぼくにとって、これらのモヤモヤをスッキリさせてくれる記事でした。

LISP 1.5が伝説たるゆえんは、「データ構造としてリストを使い、その操作と条件分岐と関数適用の仕組みを用意すれば、自分自身の評価が可能な評価器を作れる」をコンピュータで実践したことにあった！
funarg問題はLISP 1.5でも解消されていたけど、Schemeでは確かに根本的に解消されていた！
シンボルはルックアップテーブルを使わなくても実現できて、それもなんかうまい感じのデータ構造だけで作り出せてしまう！

ほかにも、こんな文字通りの風景が見えてくるようで、読んでいるだけで椅子から転げ落ちそうになります。

初期のLispはカッコを使わない表現、つまりS式ではなくM式という「いまのプログラミング言語に近い見ため」だったこと
ということは、「LispでつくるLisp」が容易なのはLispのシンタックスがデータ構造と同じだからというわけではなく（おかげでパーズは楽だけど）、ラムダ抽象と関数適用を濃縮した言語であることによるのかもしれない
というか、むしろ「LispでつくるLisp」ネタから出発してラムダ抽象と関数適用を濃縮し、それをコンピューターで動かすときの問題をひとつずつ克服していった一つの形が「LISP 1.5」だったのではないか