Posted 2011年2月23日 by 井上 & filed under いろいろ.

深町さんが既に書いていますが、WEB+DB PRESS vol61の特集記事「Scala & ClojureではじめるJVM言語」をアリエルで書きました。

JVM言語ネタでまさかのGroovy外し。と、まるでGroovyに喧嘩を売っているような記事です。しかしGroovyファンの方は怒らないでください。Groovyは特別なJVM言語です。今やJava EE界の帝国(井上の私見)、SpringSourceに愛されているからです。いずれ、Spring Framework、Groovy/Grails、Rooの3点セット(VMforceも合わせて4点セットかも)で別の特集記事をやればいい、ということにして今回の記事からGroovyが外れました。

言うまでもありませんが、ぼくはWEB+DB PRESSの中の人ではないので、こういう記事が本当に書かれるかは保証しません。伝えたいことは、Groovyが嫌いだから今回の記事にないなどのつまらない理由でないことです。

深町さんは流石に記憶力が良くて4ヶ月前のことをよく覚えています。ぼくはあまり記憶力が良くないのですが、Scalaの記事を書いてくれた岩永さんとの会話を再現してみます。

ぼくと岩永さんは普段だいたい英語で会話するので以下英語のままです。カッコでS式、ではなく日本語訳を書いておきます。

井上「Iwanaga-san, do you have time? (岩永さん、ちょっといいですか)」
岩永「Yes. (はい)」
井上「I’m thinking about an article on WEB+DB PRESS. (WEB+DB PRESSの記事についてですが)」
岩永「I see. (えぇ)」
井上「It would be about JVM language and it would contain a Scala part. (JVM言語の記事の予定でScalaのことも書きたいと思っています)」
岩永「Sounds good. (それはいいですね)」
井上「I heard you are a Scala programmer. Do you know someone who could do it? (岩永さんはScalaプログラマらしいですが、誰か書けそうな人を知っていますか?)」
岩永「Let me think… I know one person. (そうですね、ひとり知っています)」
井上「Who? (誰ですか)」
岩永「Me. I believe I am the best person except… (自分です。自分より適した人はいないと思います。ただし…)」
井上「Except? (ただし?)」
岩永「Except Martin Odersky. (Martin Oderskyは除きますが)」

記憶違いがあれば、岩永さんが訂正します。

Clackとは

　Clackを一言で説明するならば、「それぞれのWebサーバが持つ差異を吸収し、統一的なAPIを提供するためのWebアプリケーション環境」です。PythonのWSGI、RubyのRackからインスパイアされて実装しました。特に実装はPerlのPlackを参考にしています。

Clack – Web Application Environment for Common Lisp

　たとえばClackをロードしたあと、以下のようなコードを実行します。

(defun app (req)
  `(200 nil ("Hello, Clack!")))
(clackup #'app)

1

2

3

(defun app (req)

`(200 nil ("Hello, Clack!")))

(clackup #'app)

　ここでhttp://localhost:5000/にアクセスすると、「Hello, Clack!」と表示されるはずです。

Clackの利点

Webサーバを抽象化すること

　Rackの素晴らしい点は、よくこう説明されます。「WebサーバとHTTPリクエスト、レスポンスを抽象化することでWebアプリケーションをポータブルにする」。

　しかし、これだけであればClackを実装するメリットはほとんどありませんでした。Common LispにはHunchentootというLispで書かれた(しかも高速な)Webサーバが存在し、Webサーバ自身が高レベルなAPIを提供しているからです。

　あまり声に出して語られることはありませんが、Rackには素晴らしい点がもう一点あります。それはMiddlewareです。

Middlewareこそが今Lispに必要なもの

　Hunchentootが提供するAPIの上に何かをつくろうと思ったとき、アプリケーションを段階的に組み立てる仕組みがありません。Hunchentootのハンドラをマクロでラップして、ラップして、ラップして。出来上がるのはWeblocksのようなどこから手をつけていいのかわからないフレームワークになるでしょう。

　Common Lispのプロダクトはこういった設計で作られていることが多いです。竹内先生はこれを「泥団子」と表現しました。これはLispの強すぎる力によるものでしょう。他の言語では肩に力を入れて書くようなものが、マクロにマクロを重ねて簡単に作れてしまうがゆえです。

　しかし、これをどのレイヤーでも行うならば、再利用性がとても低いアプリケーションになってしまいます。部分的な利用、変更ができないカスタマイズ性の低いものになってしまいます。

　Hunchentootは必要以上に大きすぎます。URLディスパッチャだけでなく、セッション管理やログ機構まで備えています。もはや泥団子というより”そびえ立つクソ”とでも表現したほうがよさそうです。

　ClackではMiddlewareを使って、コアから切り離された処理を書くことができます。

　Middlewareはアプリケーションに直接手を加えることなくアプリケーションを拡張するための機構です。これを使えばアプリケーションに渡る前にHTTPリクエストをいじったり、返ってきたHTTPレスポンスを変更することができます。

　この設計のメリットはプロダクトを疎結合な小さな部品で構築することができる点です。

Clackが拓く未来

　Clackが既存のCLプロダクトに対して新しい点を明確にするためには、Clack上でフレームワークを作ることを考えるとわかりやすいのでもう少しClackの紹介を続けますね。

　Clackには標準でClack.App.Routeというアプリケーションをバンドルしました。これはTomohiro Matsuyamaが書いた、最小のフレームワークです。

(defpackage clack-sample
  (:use :cl :clack :clack.app.route))
(in-package :clack-sample)

(defroute app (req)
  (GET "/" #'index)
  (GET "/login" #'login)
  (POST "/login" #'authorize)
  (GET "/member/:id" #'member))

(clackup #'app)

1

2

3

4

5

6

7

8

9

10

11

(defpackage clack-sample

(:use :cl :clack :clack.app.route))

(in-package :clack-sample)

(defroute app (req)

(GET "/" #'index)

(GET "/login" #'login)

(POST "/login" #'authorize)

(GET "/member/:id" #'member))

(clackup #'app)

　URLベースのディスパッチをRubyのSinatraのように記述できます。

　defrouteはマクロであり、単純なdefunに展開されます。

　また、それぞれのディスパッチ先の処理は関数として渡せるため、Clackアプリケーションを渡すことも可能です。

　Middlewareはどうでしょう。Hunchentootではセッションを保持する機能もありますが、保存する先がメモリかDBに限定されています。一方ClackではセッションがMiddlewareとして実装されており、以下のように呼び出せば有効になります。

(clackup (builder
          (&lt;clack-middleware-session&gt;
           :store (make-instance '&lt;clack-session-store&gt;))
          #'app))

1

2

3

4

(clackup (builder

(<clack-middleware-session>

:store (make-instance '<clack-session-store>))

#'app))

　もし出力先を変えたければ、Clack.Session.Storeを継承するクラスを書くだけでFileやMemcachedにも対応することができます(僕には余力がなかった。誰か作って欲しい)。

　Clackの利点は疎結合による無限の拡張性です。本当はこの上にWebフレームワークでも書いて「ほらね？」とでも言ってあげれればいいのでしょうが、まだそこまでの余力はありません(誰か作って欲しい)。

　「Lispはどこまでも抽象化の層を重ねることができる」と言う人もいます。それは正しいのです。ドメイン特化の部分まで抽象化できるのは明らかなLispの力です。しかし、それは乱用すると再利用性のない巨大な泥団子になります。再利用できる部分は共通化する仕組みをつくるべきです。

　プログラムの世界は移り変わりが激しいです。技術を柔軟に組み合わせを変えられなければついていくのが難しくなるでしょう。5年後もHunchentootが使える世の中とは限りませんからね。

インストール

　Clackはcl-annotというライブラリに依存しているため、これを先にインストールする必要があります。cl-annotはTomohiro Matsuyamaが開発した、とてもクールなライブラリなのでいずれにしても導入することをおすすめします(この紹介記事はいずれ彼が書くでしょう)。

　残念なことにClackもcl-annotもまだQuicklispのリポジトリに入っていません(申請中)。使うにはそれぞれGitHubからダウンロードする必要があります。

　まずASDFの設定をします。ここでは~/lisp/systems/にライブラリを放り込むように設定しています。

$ mkdir ~/lisp/systems

1	$ mkdir ~/lisp/systems

　そして~/.config/common-lisp/source-registry.conf.d/01-add-local-lisp.confに以下のように記述します。

(:tree (:home "lisp/systems/"))

1	(:tree (:home "lisp/systems/"))

　これで~/lisp/systems/以下に置いたライブラリはすべてql:quickloadできるようになります。

　次にgit cloneします。

$ cd ~/lisp/systems
$ git clone git://github.com/arielnetworks/cl-annot
$ git clone git://github.com/fukamachi/clack

1

2

3

$ cd ~/lisp/systems

$ git clone git://github.com/arielnetworks/cl-annot

$ git clone git://github.com/fukamachi/clack

　あとはQuicklispでロードすれば依存パッケージもダウンロードされ、使える状態になるはずです。

(ql:quickload :clack)

1	(ql:quickload :clack)

まとめ

　Clackは何人かの友人のフィードバックを得ながら開発されました。Tomohiro Matsuyamaは実際にClackを使い、疎結合による開発のメリットを深く理解してくれました。

　Emacs Lispで有名なKenji ImakadoはClackからCommon Lispに興味を持ち、その上にフレームワークを作り、実際に使いたいとすら言ってくれました。

　現在考えうる限りで、Clackは間違いなくCommon LispでWeb開発するために最適な環境です。ぜひ使ってほしいです。

元記事 : Common LispがWeb業界を駆逐するとき – Revenge of Lisp in Web

ラムダ式

以下の形式のフォームをラムダ式と呼びます。ラムダ計算においては厳密にはラムダ抽象と呼ばれるのですが、Common Lispではラムダ式と呼びます。

(lambda (...) ...)

1 2	(lambda (...) ...)

プログラム内で、そのまま(lambda (...) ...)と書くと、コンパイラによって別物（後述）に変換されるので、通常はquoteを使ってラムダ式を表現します。

CL-USER&gt; '(lambda (x) x)
(LAMBDA (X) X)

1

2

3

CL-USER> '(lambda (x) x)

(LAMBDA (X) X)

ご覧の通り、ラムダ式は普通のリストと何ら変わりがありません。

ラムダ式の`funcall`

せっかくラムダ式を定義したのですから、ラムダ計算の最も重要な操作であるβ簡約（ここではfuncall）を定義しましょう。

(defun my-funcall (lambda-form &amp;rest args)
  (if (and (consp lambda-form)
           (eq (car lambda-form) 'lambda))
      (let* ((lambda-list (cadr lambda-form))
             (lambda-body (cddr lambda-form))
             (form
              `(let ,(loop for formal in lambda-list
                           for arg in args
                           collect `(,formal ,arg))
                 ,@lambda-body)))
        (eval form))))

1

2

3

4

5

6

7

8

9

10

11

12

(defun my-funcall (lambda-form &rest args)

(if (and (consp lambda-form)

(eq (car lambda-form) 'lambda))

(let* ((lambda-list (cadr lambda-form))

(lambda-body (cddr lambda-form))

(form

`(let ,(loop for formal in lambda-list

for arg in args

collect `(,formal ,arg))

,@lambda-body)))

(eval form))))

Common Lispに詳しくない人のために簡単に説明しますと、このmy-funcall関数は、ラムダ式の引数リストと、my-funcallに渡された引数とのリストで、let束縛を持つフォームを生成し、そのフォームをevalすることでβ簡約（funcall）をエミュレートしています。例えば次の式を考えてみます。

CL-USER&gt; (my-funcall '(lambda (x y) (+ x y)) 1 2)
3

1

2

3

CL-USER> (my-funcall '(lambda (x y) (+ x y)) 1 2)

3

この時、my-funcallは

(let ((x 1) (y 2)) (+ x y))

1 2	(let ((x 1) (y 2)) (+ x y))

というフォームを生成してevalします。その結果、funcallと同じような効果が得られるわけです。

第一級オブジェクトとfunarg問題

ところで、他の関数にラムダ式を渡したり、関数の返り値としてラムダ式を返せたら便利だと思いませんか？あるプログラミング言語がこのような性質を備えているとき、ラムダ式は第一級オブジェクトと呼ばれます。また、ラムダ式を受け取ったり返したりする関数を高階関数と呼びます。当然ながらCommon Lispもこの重要な性質を備えています。

ラムダ式を第一級オブジェクトとして扱うにあたって考えなければならないのが、ラムダ式の自由変数を誰が補足するか、という問題です。例えば次の例を考えてみます。

(defun make-adder (x)
  '(lambda (y) (+ x y)))

(let ((x 1))
  (let ((adder (make-adder 2)))
    (my-funcall adder 3)))

1

2

3

4

5

6

7

(defun make-adder (x)

'(lambda (y) (+ x y)))

(let ((x 1))

(let ((adder (make-adder 2)))

(my-funcall adder 3)))

make-adderは整数を受け取って、その整数に別の整数を足す関数を返します。二つ目の式はxを1に束縛した後、2を足すadder生成し、そのadderに3を渡しています。この式は実行可能な正しい式ではありませんが、重要なのは、(my-funcall adder 3)の時にどのxが参照されるべきか、という点です。make-adderのxを無視するなら、評価結果は4になりますし、(let ((x 1))のxを無視するなら、評価結果は5になります。このように、ラムダ式をデータとして表現したときに発生する、自由変数の補足（環境）の曖昧さの問題を、funarg問題と呼びます。

`function`スペシャルフォーム

funarg問題を適切に解決するためには、評価時にラムダ式を関数クロージャ（または単にクロージャ）に変換する必要があります。関数クロージャには、関数クロージャが生成されたときの環境が記録されているため、上記したfunargの問題が発生しません。その変わり、ラムダ式を関数クロージャに変換する特別な構文規則が必要になります。Common Lispでは、functionスペシャルフォームがその役割を持っています。functionスペシャルフォームは、与えられたラムダ式を、現在の環境を閉じこめた関数クロージャに変換します。

CL-USER&gt; (function (lambda (x) x))
#&lt;Anonymous Function #x30200111920F&gt;

1

2

3

CL-USER> (function (lambda (x) x))

#<Anonymous Function #x30200111920F>

上記したfunarg問題の例をfunctionスペシャルフォームを使って書き直してみましょう。

(defun make-adder (x)
  (function (lambda (y) (+ x y))))

(let ((x 1))
  (let ((adder (make-adder 2)))
    (funcall adder 3)))

1

2

3

4

5

6

7

(defun make-adder (x)

(function (lambda (y) (+ x y))))

(let ((x 1))

(let ((adder (make-adder 2)))

(funcall adder 3)))

評価結果は5になります。funarg問題はちゃんと解決されているようです。

`#'`と`lambda`マクロ

ラムダ式をいちいちfunctionスペシャルフォームで囲わないといけないのは面倒ですよね。そこでもっと簡潔に書くために#'リーダーマクロが導入されました。例えば

#'(lambda (x) x)

1 2	#'(lambda (x) x)

は

(function (lambda (x) x))

1 2	(function (lambda (x) x))

に展開されます。

ただ、#'を書くのも面倒ですし、#'を忘れてしまうとエラーになってしまいます。そこでlambdaマクロが導入されました。例えば

(lambda (x) x)

1 2	(lambda (x) x)

は

#'(lambda (x) x)

1 2	#'(lambda (x) x)

に、つまり

(function (lambda (x) x))

1 2	(function (lambda (x) x))

に展開されます。仕様書には次のように記載されています。

    (lambda lambda-list [[declaration* | documentation]] form*)
 ==  (function (lambda lambda-list [[declaration* | documentation]] form*))
 ==  #'(lambda lambda-list [[declaration* | documentation]] form*)

1

2

3

4

(lambda lambda-list [[declaration* | documentation]] form*)

== (function (lambda lambda-list [[declaration* | documentation]] form*))

== #'(lambda lambda-list [[declaration* | documentation]] form*)

最初のlambdaはlambdaマクロを持つフォームであって、ラムダ式ではないことに気をつけてください。後ろの二つはどちらもラムダ式です。

実際の歴史が上記したストーリーを経ているかは、僕は確たる証拠を持っていません。Webで見つけた情報を適当に編纂しただけですので、間違いがあったら教えてください。

`#'(lambda (...) ...)`

ところで、仕様書にlambdaマクロが含まれているのにも関わらず、多くのライブラリのソースコードで

#'(lambda (...) ...)

1 2	#'(lambda (...) ...)

と記述されているのを目にします。本質的には、この#'は必要ないはずなのですが。

噂では、lambdaマクロを持っていない古い処理系に対応するためらしいですが、それならlambdaマクロを別途定義しちゃえばいいじゃん、と思ってしまいます。また、ポール・グレアムは上記の記法を推奨しているという話も耳にはさみました。ソースが分からないので、その理由はまだ確認していません。とにかく、僕には今のところ、この#'を書くべき理由が見つかりません。

シンボルに`#'`をつけるべきか

Common Lispのややこしいところは、#'を付けなくてもfuncallできたりするところです。

(funcall '+ 1 2)
(funcall #'+ 1 2)

1

2

3

(funcall '+ 1 2)

(funcall #'+ 1 2)

どちらも3を返しますが、この両者に確たる違いはあるのでしょうか。実はこの二つでは、シンボルの関数セルから関数を取り出すタイミングが異なります。'+のほうはfuncallが+から関数を取り出しますが、#'+のほうはfunctionスペシャルフォームが+から関数を取り出します。そのため、以下のように高階関数に関数を渡すときは#'を付けるほうが、一般的にルックアップのコストが低くなります。

(find-if 'stringp '(1 2 "a" 3))  ; 少し遅い
(find-if #'stringp '(1 2 "a" 3)) ; 少し速い

1

2

3

(find-if 'stringp '(1 2 "a" 3)) ; 少し遅い

(find-if #'stringp '(1 2 "a" 3)) ; 少し速い

また、#'を付けておけば構文的にその評価結果が関数であることが分かるので、コンパイラによる最適化が望めます。つまるところ、シンボルを関数として利用する場合は、基本的に#'をつけておくべき、というのが結論になります。

ラムダ式の特別ルール

予備知識として知っておいて欲しいのですが、ラムダフォームと呼ばれる次の形式

((lambda lambda-list . body) . arguments)

1 2	((lambda lambda-list . body) . arguments)

は、構文的に次の関数フォームと同じです

(funcall #'(lambda lambda-list . body) . arguments)

1 2	(funcall #'(lambda lambda-list . body) . arguments)

つまり、関数フォームの関数部分にラムダ式が指定されている場合のみ、特別にfuncallが補われるということになります。これはマクロを書くときに重宝するので是非覚えておいてください。

まとめ

今回はCommon Lispのlambdaにまつわる話題を提供しました。記事では触れられていない話題もあると思いますので、もし詳しい方がいらっしゃればコメントで教えていただければ幸いです。なおこの記事は、同僚の深町さんと一緒に、一週間ごとに交代で書くことになったCommon Lispシリーズの記念すべき初エントリーです。深町さんは文筆家なので、僕などボコボコにされるのがオチだと思いますが、楽しみにしていただければと思います。