Shibuya.lisp TT #8 で「Redesigning Common Lisp」という発表をしました
先日8/30(土)、Shibuya.lisp Tech Talk #8 が開催されました。
イベント概要
イベントではTechnical Talkが5つ、Lightning Talkが9つありました。
参加者は全部で57名。よく使うLisp方言のアンケートを取ったら、だいたいCommon Lisp、Scheme、Clojureが1/3ずつくらいばらけていました印象です。コミュニティ内に多様性があるのは非常に良いですね。
各発表も話題が多様でした。
- Schemeの教育学習分野への応用 (Scheme)
- Clojureの高品質なシンタックスハイライター (Clojure)
- Redesigning Common Lisp (CL)
- KOMADORIによる対話的画像処理 (CL)
- 型宣言を付けたら遅くなった話 (CL)
- Shenについて (Shen)
- 授業で半年間moclを使ってみた (CL)
- 床下LispとLisp Meet Up (muLisp)
- Picrinについて (Scheme)
- Clojureの型推論器 (Clojure)
- cl-cuda: a library to use NVIDIA CUDA in Common Lisp (CL)
- ClojureのIncanter (Clojure)
- Om (Clojure)
- 42言語のLisp実装
とても内容の濃い一日だったと思います。
途中@nobkzさんの発表で、「弊社、Lisperを募集しています!」という求人募集もありました。いいですね、こういうの。
発表しました
僕もTechnical Talkで「Redesigning Common Lisp」と題して40分程度の発表を行いました。
新しくLispエイリアン色のプレゼンテーマを作って使ってみました。
内容は僕が今年始めたプロジェクトの一つの「CL21」についてです。
質問や意見も多くいただきました。ありがとうございました。
話さなかったこと: CL21のこれから
時間の関係と少し話がそれてしまうという理由で削ってしまったことについて補足します。
CL21はこれからCommon Lispの再整理を行い、より小さな言語カーネルを目指す予定です。
Richard GabrielのWorse Is Betterという記事に、言語を4層に分離するという方法が提案されています。
言語は少なくとも4つの層に分割されるべきだ:
- 言語カーネル。この層は単純で実装しやすいものとなる。どんなケースにおいても、動的な再定義は再考を加えて、このレベルでのサポートが必要かどうかを判断するべきだ。私は再定義可能なものがカーネル内に必要だとは思わない。
- 言語を肉付けする言語学的な層。この層は実装上の困難が若干伴うかもしれない。そしてここには多分、カーネルで実装するには高価すぎるが割愛するには重要すぎる動的な側面が含まれることになる。
- ライブラリ。Common Lispにあるものの大半はこの層に置かれる。
- 環境として提供されるエピ言語的機能。
1番目の層に私は、条件式、関数呼び出し、すべての基礎データ構造、マクロ、単値、非常に基礎的なオブジェクト指向のサポートを含める。
2番目の層に私は、多値とより進んだオブジェクト指向サポートを含める。2番目の層は、環境が提供するに任せるにはあまりに重要すぎる、難易度が高いプログラミング上の構造、しかしそれでいて正確な定義を正当化するだけの意味論的な重要性が十分にある、そういうもののためにある。何らかの形の再定義機能はここに置かれるかもしれない。
3番目の層に私は、シーケンス関数、手の込んだ入出力関数、その他1番目の層と2番目の層に単純に実装できなかったものすべてを含める。これらの関数はリンク可能であるべきだ。
4番目の層に私は、環境が提供でき、またそうすべきであるが、標準化されなければならない機能を含める。典型的な例はCLOSのdefmethodだ。CLOSでは、総称関数はメソッドから成っており、各メソッドは特定のクラスに適用可能である。1番目の層には完全な総称関数のための定義式――つまり総称関数およびその全メソッドの定義が一箇所に集まったもの――がある(第1層のコンパイラがそれらをどう見たいかを反映している)。名前を総称関数に結び付ける手段も用意される。しかしながら、システムを発展させていく途上で、クラスはさまざまな場所で定義され、関連した(適用可能な)メソッドがクラスの隣に見えたほうが道理にかなっている。メソッドを作るその仕組みはdefmethodで、defmethod式は他の定義式の中のどこにでも置ける。
この方法には2つのメリットがあります。
- 何をどこのレイヤーに入れるべきか、または入れないべきかの議論の基準が明確になる
- CL処理系の実装が楽になる
CL21における議論で、「この機能を追加してよ」というものはかなり多いですが、それがどの層に属するのか、同じレイヤーの他の部品と比較して汎用性は十分にあるか、などより具体的に話し合うことができます。
もう一つのメリットである処理系の実装を簡単にするのは、実行環境が(再び)多様化しつつある昨今で、実行環境が生き残っていくために必要かなと考えています。
たとえばJSCLというJavaScriptで実装されたCL処理系がありますが、JavaScriptという独特の難しさを抱えており、CLの仕様をすべて満たしきれないでいます。この視点での言語の4層分離は必要そうです。
CL21の現状
こういう話を踏まえて、CL21の現在のステータスを話すと、「約束できることは何もありません」。
まだ議論も続いていて、何もFixできる状態でなく、早々の安定化を目指すよりも本来の目的である「Experiment (実験)」することの意義を優先しています。
何か良いアイデアをお持ちの方はGitHub Issuesでの議論に参加してください。
まとめ
Shibuya.lisp Tech Talk楽しかったですね。運営スタッフの方々お疲れ様でした。会場を貸していただいた株式会社mixiの鈴木さん、ありがとうございました。
また、Shibuya.lispは月一のMeetUpイベントも開催しています。
次回は来月下旬に開催予定なので、興味がある方はぜひ参加を検討ください。