星田さんの記事に対するコメント。
> 2021/11/15
宿直のお供に「On Lisp」を持ち込む。なんかいきなりムズい・・と言うかなんか頭に入ってこないような？
うん。ムズい。
ポール・グレアムって人は拙速なんですよね。
んで、個人的には。
On Lispって本は「マクロ」に関しての博覧本だとは思います。
なんつーのかね。ある種マクロのリファレンスとして手っ取り早く調べるにはよくまとまってる。
が。しかし。
本として購入するなら、以前言ったように実用Common Lispの方が値段は高いけど同等レベルのマクロは学べる本なんですよ。
しかも、On Lispはあくまでぶっちゃけ「ユーティリティ」を論じる本だけど、実用Common Lispは「プログラミング」に付いて書いている。
そしてOn LispはCLtL2に対する本だけど実用Common LispはANSI Common Lispに対しての本だ。
またOn LispはWeb上で読めるけど実用Common Lispは読めない。
そういう処々の理由があって、On Lispは敢えて推薦しなかったんです。
関数、いくらでも新しいのが出てくるなぁ・・・と思ってたけど、700！って！そして更に恐ろしいのは、この上まだマクロを使って必要と思った機能を追加するという貪欲さですかね・・
んで、その700の関数の結構な部分が木構造操作に対しての関数なんですよね。
C言語辺りだと「データ構造とアルゴリズム」とか題した講義での宿題になるネタなんでしょうが、Lispはリストがあるので、木構造を作るのは古典的ながらも簡単。よってそれの操作関数が豊富にあって、「探索」と言われる分野に非常に強い言語になってる。
List ProcessorならぬTree Processorだ、ってのがANSI Common Lispの一つの側面です。
現代のプログラミング言語で、木構造を弄るのが得意な言語は恐らくANSI Common LispとHaskellの二つくらいなんじゃないでしょうか。
ただ、ANSI Common Lispは同時に、歴史的な経緯で入ってるのか、よく分からん関数もあるんですよ(笑)。なんせそれまでの多くのLisp方言を「まとめよう」と言った趣旨があったんで。
代表的な「よく分からん」関数は次の二つでしょうね。
・ED
以前にも書いたけど、エディタを立ち上げる関数・・・・・・現代的な観点だとエディタからプログラミング言語を呼び出すのはフツーだが、逆にプログラミング言語からエディタを呼び出す必要があるのか・・・よく分からん。
エディタから呼び出したプログラミング言語からまたエディタを呼び出し、それからまたプログラミング言語を呼び出し・・・と言う現実的な再帰の実例だとすれば、なるほど、Lispらしいが、もちろん実際的な意味はない。
・・・・・・ごめん、やったことあるわ(笑)。Linux環境だとvimが立ち上がるんで、vimからCommon Lispを呼び出してそこからedコマンドでvimを立ち上げて、またCommon Lispを呼び出して・・・って遊んだ事はある(苦笑)。
はい、いいえ、を尋ねるだけの関数・・・・・・え、それだけ(爆?
うん、確かにユーザーに「はい」か「いいえ」を尋ねるケースは多いけど、「よく使われるから」とこんなバカな関数がビルトインになってる、ってのもANSI Common Lispだけなんじゃなかろうか(笑)。この関数の存在を知った時、30分くらい腹を抱えて笑ってた(笑)。
あと、これもformat絡みなんだけど、例えばANSI Common Lispだとローマ数字印字機能なんつーのもあんのね。・・・・・・一体誰がこれを望んだんだろう(笑)。日本じゃ考えられない機能だ・・・・・・。
格式高い映画の著作権の年号表記に出てくるローマ数字の例。
2021はローマ数字でMMXXIになる事が分かる。・・・分かるからどーした、ってもんじゃないが。こんな事が可能なら、どーせなら次回改訂があるとすれば、数字を漢字に直して出力する機能も付けてもらいたいモンである。
とまぁ、1958年登場のLispの歴史の集大成、的なのが間違いなくANSI Common Lispなわけです(登場初期のLispのシンプルさに戻ろうとしたSchemeとは、そういう意味でも対象的なわけです)。
余談ですが、ANSIになる前、取り敢えず草の根運動的に「Lisp方言を(出来れば)一つに纏めようぜ!」と仕様を決めて出版されたのが1984年のCommon Lisp the Languageですが。
当時から「電話帳のような厚さ」の仕様書で、決めたはいいけど
「こんな厚さで一体誰が実装出来るんだ?不可能だわ!」
と批判の嵐。
実際、仕様がデカすぎて実装が頓挫したと言って良いALGOLの二の舞、なんじゃねーのっつー「バカな言語」がCommon Lispだった。
ところが、その「バカで」「巨大な」仕様を実装しちまった奴らがいたんだな・・・・・・。日本でだ。
実は、世界初のCommon Lispの実装は日本の京都大学で行われて、その実装のお陰でCommon Lispの実装は不可能ではないと言う事が知られるに至った、ってわけ。
その日本で作られたANSI以前のCommon Lisp実装がKyoto Common Lisp(KCL)と言う処理系で、後にGNUに寄贈されてGNU Common Lisp(GCL)となります(ただし、ANSI実装を目指してるけど、現在でも到達してません)。
Kyoto Common Lisp/GNU Common Lispの面白い特徴は、当時はC言語のコンパイラの最適化研究が発展期であり、C言語のコンパイラの性能上昇に賭けて、Lispコンパイラとしては機能を丸投げした辺り(笑)。
言い換えると、実はKCLはコンパイラと言うよりCへのトランスレータとして割り切った設計にしたってのが特徴です。
そしてそのお陰で「バカでかいCommon Lisp実装の開発労力を低減した」と。
ひっじょーに、アタマの良い割り切りで作られてます。だから世界中のLisperが驚いたらしい。「こんな方法があったのか」と。
今となっては古典的実装ですが、今でも数式処理システムMaximaのコンパイラとして使われています。
また、Common LispとC言語を連携させたい、ってニーズはそこそこあって、「C言語へのトランスレータ」として、Embeddedable Common Lisp(ECL)と言うGCLからフォークした処理系も存在して、ニッチですが、そこそこ人気はある模様です。
