本を読む

読書やコンピュータなどに関するメモ

「Shibuya.lispテクニカルトーク#3」観覧

　Lispコミュニティ「Shibuya.lisp」のテクニカルセミナーイベント「Shibuya.lispテクニカルトーク#3」が開催されました。今回はGaucheの川合史朗（Shiro）さんも登壇するなど、やはりすごく面白い話をいろいろ聞けました。

　以下、観覧メモ。間違いがあったらご指摘ください。

　今回は、メイントークでCommon Lispの2件も継続を活用していたのが印象的でした。継続は力なり。あと、Lispとは関係ありませんが、なぜかプレゼンターのうち2人もタイル型ウィンドウマネージャを使っている方がいました。

開会の挨拶（佐野匡俊）

　前回からのアップデートが紹介されました。なんといっても、Shiroさんが開発した、Lingrを継ぐチャット「Chaton」が大きいトピックでした。一方、逆引きCL/Scheme/Clojureは停滞ぎみで、知りたい側の人の声が欲しいとか。

　次回のテクニカルトークはだいたい4か月後だけど詳細未定とのことで、まずは初回のようにスタッフのキックオフミーティングを開いて意気を上げることを考えているそうです。さらに、ネットをあまり見ずに研究してる人とかも交流したいという話も聞かれました。

世界一短いコードでwebアプリ作成ができるフレームワーク開発（松本智行）

　Common LispでWebアプリケーションフレームワーク「web4r」を開発した話でした。「プログラミングGauche」を読んで本格的にLispに入り、ほかの仕事はすべて断って未踏プロジェクトとして開発していたんだそうです。なので、アドバイスを期待したいとのことでした。

　web4rは継続ベースのWebアプリケーションフレームワークで、Arc、Kahua、Railsの影響を受けているそうです。記述の短さを最優先にしていて、冗長性を削りつつ、マクロで構文をいじったりCPSを活用したりしているとのこと。客席にはRubyのSinatora関係の人もいて、Sinatoraもコードが短いですねという話になっていました。

　まず、S式でHTMLを表現するマークアップする独自開発の「sml」を紹介しました。リーダーマクロでprintの式に展開するのだそうです。CSSふうのセレクタでエレメントを操作したりもできて、スペシャル変数の値でマークアップ言語（HTML、XMLなど）を変更する機能もあるそうです。「cl-whoとかを使わなかった理由は」という質問もあって、cl-whoはリストで渡すから長いのが嫌で、実はそのツッコミはよくもらうのでFAQにしたとの回答でした。

　Webサーバーとしてはhunchentootを利用。ページのアクションはdefun風のdefpage式で定義するようになっていて、引数としてURLやget・postなどのパラメタを受け取るそうです。CPSによるセッション管理はweb4rの特徴なのですが、継続を持ち続けるとメモリがいっぱいになってしまうので、1度呼び出したら破棄するようにしているとのこと。これはいちばん相談したいポイントだったようで、1度で破棄しちゃうとBackボタンに対応できないという問題点が指摘されたり、Kahuaでもそのへんは難しいとかheartbeatで監視して破棄しようかとかいうShiroさんの話もありました。

　面白かったのが永続化クラスというものです。これは、Railsでいうモデルのようなものと解釈しました。クラスのスロットがレコードのフィールドに対応して、そこに拡張オプションで挙動を指定するそうです。defpclassで永続化クラスを指定すると、あとはgenpages関数を呼び出すだけで雛形アプリができるというscaffoldっぽいことができて、会場から驚きの声が上がりました。ちなみに、「ちゃんと複数形も使ってますよ」とRailsな人向けのネタもありました。永続化クラスについてはShiroさんから、面白いし自分も昔考えたけど、たとえば性別の値によって項目をdisableしたりするなどの関連づけをすると大変になる、という体験談もあり、それに対して:hide-for allオプションを紹介しつつ、もう少し考えてみるという回答でした。

　ちなみに、「Lispコミュニティは初心者にやさしくないという声がある。これは真っ赤な嘘」というのも語られました。irc（ただし英語）でとても親切に教えてもらったそうです。ただし、日本語の情報はまだ少ないかもという話もありました。

R5RS完全準拠JVM日本語Schemeインタプリタ「Gino（仮）」（ilma）

　コミュニティや学会などには参加していなくて、ずっと独学でコツコツSchemeインタプリタを作ってきたという報告でした。年内に公開予定とのことです。

　Javaの上で二進木評価装置を作ったのをベースに、S式パーサを追加したりして、R5RS完全準拠のSchemeインタプリタを作ったそうです。処理系がgino.jarという1つの380KBのjarになっていて、最小メモリは4MB（JVM自体は除いて）。厳密なR5RSをベースにしているのでevalの引数が1つだとエラーになるのだけど、そのあたりの互換性をオプションで変更できるんだそうです。互換性の変更は、エラー処理のところで関数名を見てフックして処理しているそうです。

　ネットワークポートも使えて、TCP/IPごしのREPLを実演していました。

　面白かったのが、日本語でエラーメッセージが表示されること。これはJavaのロケール機能を使っているので、LANG=Cを指定すると英語でエラーメッセージが表示されるというデモもなされました。

　ほかに独自機能で面白かったのがトレース機能です。トレース機能を指定して実行すると、どの式が評価されてどういう値になり、それがどの式にどう渡って…という関係がツリー状に図示されます。継続の部分はツリーが切れて、これで初学者が継続を理解する助けになるのではないか、との話でした。

teepeedee2: fast IO in Lisp（John Fremlin）

　全部Common Lispで書いた高速なWeb（アプリケーション）サーバーの発表でした。発表者は、第2回テクニカルトークで、S式による高速正規表現ライブラリcl-irregsexpを発表した方です。発表が英語でしたし、Common Lispの黒魔法みたいなマクロ技を使いまくっていて、私はちゃんと理解できてません（汗）。

　COMETで通信してチャットやゲームをするようなのを想定しているそうで、大量のコネクションにも耐えるし、今話題のslowlorisでもダメージなしというのがポイントでした。1プロセス・1スレッド・1コアの上で、継続によるユーザースレッドでセッションをさばくとのことです。I/Oも、Linuxではepollを使ってノンブロッキングで処理するそうです。このあたり、COMETということで、Chaton開発者のShiroさんも反応していました。

　印象的だったのは、Common Lispのコンパイラにうまく乗るように作ったマクロなどの黒魔術でした。my-defunとmyというのがあってmy-defunの中でmyをスロットアクセスに使うとC++のように決めうちで速い（？）とか、defun-consistentはできるだけ定数にコンパイルしちゃう（？）とか、正直わかってません（汗）。ちなみに、文字列はエンコードとかすると遅いからバイト列で処理しちゃうんだそうです。

　Webアプリケーションの処理としては、web4rとも通じるdefpageとかHTML出力とかCSS出力とかをサポートしているところを見せました。さらに、ゲームを簡単に作れるDSLを紹介し、defgameとかdefplayerとかdefrulesとかを使ってポーカーゲームを作ってみせていました。

Inside c-wrapper（小黒直樹）

　GaucheからCのライブラリをそのまま呼べるようにするc-wrapperの紹介でした。(c-load "hoge.h")とかすると、hoge.hで定義されているライブラリ関数やデータ型を、Gaucheの関数やクラスとして使えるという驚きのしくみです。プレゼンは、「まんがでわかるLisp」のクダーと女の子（名前忘れた）を案内役に、ブロック崩し（breakout）をGaucheで作る過程を見せて、場内爆笑でした。

　考えとしては、Gaucheで拡張ライブラリを作るとstubを作るのが面倒で本体にたどり着くまでに疲れちゃうので、ヘッダファイルをパースして情報を得て使おうというものだそうです。そのため、よくも悪くもCの関数そのままの形式やメモリ管理になるそうです。Gauchaの関数もCの関数ポインタに変換するので、Cのライブラリにコールバック関数としてlambdaを渡せるのがいいですね。ただし、GCから保護するためにこのlambdaはハッシュテーブルに登録しているので、自分でハッシュテーブルから削除しないとメモリに残りっぱなしになっちゃうそうです。

　ただし問題になるのは、関数マクロやインライン関数などライブラリのシンボルテーブルにない「見えない関数」。これについては、ヘッダからパースした結果をS式に変換して関数にしているそうです。関数マクロは文字列操作なので関数にするには限界がありますが、実際にはいまのところ問題にぶつかっていないとのことでした。

　あと、ヘッダのincludeをたどっていくと、たとえばreadシステムコールの定義がパースされて、Gaucheのread関数が上書きされてしまっちゃったりという問題が起こりえます。そこで、c-loadに:importオプション（インポートするシンボルを指定）と:hide-symbolsオプション（インポートしないシンボルを指定）というオプションを設けて対応しているそうです。これには、たとえばgtkをそのまま読み込むと16,000シンボルをパースして定義しようとして遅いので、:importでパース対象を絞って高速化、という使い道もあるそうです。

　高速化としてはほかに、パーサをCで書き直したり、オブジェクト変換のオーバーヘッドを抑えたり、eval処理の時間を短縮したりといったチューニングをして、130倍速くなったそうです。パース結果から共有ライブラリをあらかじめ生成しておくcwcompileという機能も作ったそうで、インライン関数の制限がなくなるとか、Mac OS XでSDLを使うときの問題（スタティックライブラリを参照する）を避けるのに使ったりというメリットもあるようです。Mac OS Xといえば、dlloadが遅いので遅延ロードするという対策もやったそうです。

(現場のScheme)と(Gaucheの進化) （川合史朗）

　川合史朗（Shiro）さんのセッションは、「仕事でLispをするということ」と、「そのためにGaucheをどう使うか、どういう仕様を追加するか」が結びつけられて語られ、すごく印象的でした。

　Shiroさんは、自分のプログラマとしての仕事を「動くプログラムを納入することが至上命題」とし、自分を「モンスター退治の雇われ勇者」になぞらえ、「Gaucheという武器を常に磨いておく」ための必要をGaucheの進化の目的と語りました。

　以下、まとめきれないので箇条書きで。ちなみに、語られた機能はまだunofficialな構想で、無保証とのことです。

性能
- 「常に最速である必要はないが、確実に要求を満すには必須」
  - 確実に下限は切らない
- 「Cで書かれた部分が律速」という人もいるが、実際には5割VM、3割GC、2割がCルーチン
- GBオーダーのデータセットも日常的に扱う時代に

まっとうな手段もあるが、納期によってその場しのぎもアリ
- 禁断の果実Macro
  - Gaucheのクラスは遅い。スロットアクセスとか
  - そこで、マクロを使ってベクタで代用
  - これは近い将来、組み込みのreord型に進化予定
compiler macro
- いまtrunc
- あとでapiを用意
beyond copompiler macro
- macroからは外の環境を見るのは難しい
- あとからわかる情報は使えない
- シビアな制限
  - C++のテンプレートではできたりすることも
- メタな情報を使えるマクロの構想
「schemeが遅ければCで書けばいいじゃない」
- extensionにするのは手順的に重い
- 「この関数だけCにしたい」という用途とか
- linline-stub
  - schmeソースの中に書ける
  - schemeのようなC
    - cise (C in S-expression)
    - 「私はなんべん無駄なforを書いたんだろう」
- inline-stub + AOT compiler（後述）
  - ATOコンパイルされてなければ、ソース上でスルーされるだけ

地道でまっとうな改善
- JIT
  - v8に刺激されて実装してみた
  - 倍ぐらいのスピードになった
  - ただし、実装よりメンテの手間が問題なので、様子見
- no consing重要
  - たとえば、関数のoptional引数はリストになるが、分解するだけ
  - スタックに置いてリストにしない仕様を実装
- 浮動小数点数
  - 1ワードに入らない
  - ナイーブな実装だとヒープに置く
    - GCが多発
  - 専用のレジスタバンクに置く手法の論文を書いた
    - 一種の世代別GC
    - truncに
  - 「もうヒープにアロケートする時代ではない」

Conservative GCの限界
- Boehm GC
  - Cのポインタに見えたらポインタにする
  - hashtableのchainedでfalse pointerになりがち
- Compact Trieを使ってsparce tableを実装
- util.sparse

Concurreency
- ハードの力でパワーアップしようという案件もあるので、それに対応
  - thread-safe queue
  - thread pool / process poool
  - lock-free / wait-free data structure（未定）
  - immutability（clojureのような）（未定）

簡潔さ
- 「自分が生き残るために必要」
  - 4年前に納品したコードに機能追加、という案件
  - 5万行あったらたいへん
関数名を短くするとかの、見かけの短さも、実は馬鹿にできない
- lambdaを^におきかえるとか
  - 入れる予定
- スロットのリファレンスを~で
- haskellの「$」は迷っている
- CLスタイルの引数はtruncに入れた
  - :optional、:key
- util.matchへは組み込みへ。match-lambda。「^*」という短縮名
  - 関数型言語っぽい記法も？

パージングにPEG
- util.peg
- 性能上の問題が未解決

多相
- generic-functionのディスパッチが重い
- メソッドキャッシュ、型宣言/推論？
- mapとかは多相にして、list-mapとかを設ける？

lazyness
- 必要ないのに1,000要素を作る必要はない
- util.generator：Pythonのジェネレータふう
  - まだ予告

関数の探しやすさ
- メタ情報の検索サブシステム
- emacsで、勝手にuseを追加してくれる機能とか

パッケージング
- ソースを出したくないというお客さんからのリクエスト
- AOT（ahead of time compilation）
- Cに変換してコンパイルしてDSOに

Q: 短くするメリットとデメリットがあるが
- A: いろいろやってみて。lamdaを短くするのはみんなが得
Q: 多相型の高速化
- A: キャッシュすると速くなるが、Gaucheでは難しい
Q: ^* の形式はemacsでS式単位の移動がめんどうそう
- A: 短くすることとのトレードオフ
Q: R6RSはコアが大きくなって、Haskellやclojureにユーザーが流れた。これに対してどう思うか
- A: もともと流れるほどのユーザーがいたのかどうか（笑）
- GaucheもR6RS対応モードは設ける考え。すべて対応というわけではなく、モジュールにしたり
- R6RSはひとつのオプションであり、R5RSもScheme
- たいていはちょっといじれば動く。そんなことを考えるよりSchemeのコードを書こう

LT: Scheme on Ruby on Rails（Yuumi3）

　ここからLT。今回のLTはQ&Aありでした。

　一番手は、第2回でGauche on Railsを発表したYuumi3さん。今回は逆に、Ruby上でSchemeふうの記法でRuby on Railsの処理を書けるようにしたという新技でした。仕組みとしては文字列を処理してRubyのメタプログラミングとして処理しているそうです。マクロにも対応したいとか。

LT: WebブラウザをインターネットOSのシェルにしてGaucheと対話する（源馬照明）

　インスタントメッセンジャーのプロトコル「XMPP」経由で使えるGaucheのREPLボットを作った話です。最初はおとなしくPidginでデモしたのですが、次にFirefoxの拡張機能版のクライアントを使うとCOMETのチャットみたいになって、さらにbotからcanvasに描画するJavaScriptを返すように変更するとSchemeの式でブラウザに描画できる、という展開が面白かったセッションでした。

LT: 失敗したら会社終わるようなプロジェクトでLispを使ってみた（mitamex）

　第1回テクニカルトークで発表された、携帯Javaアプリに組み込むLispインタプリタ「l4u」のその後で、実際に半年仕事で使った様子がレポートされました。

　やってみてわかったこととして、開発環境やライブラリー、ドキュメントの整備がたいへんだったそうです。やっぱり製品自体を作りはじめたらそっちのほうにパワーをかけることになりますよね。ちなみに、第1回でこだわっていた「携帯端末のREPL」は、作ったものの、使われていないんだとか。

　現場ではLispっぽい書きかたはされていないそうで、JavaScriptっぽいプログラミングがされているそうです。そういう意味でもAlgolっぽい糖衣構文にしてよかったというのを「どんないいひとだって、初めて会ったとき素っ裸だったら走って逃げられる」という比喩で語っていました。括弧は全裸ですか（笑）

　あと、クライアントとサーバーの両方を作ったけど、サーバーに投入するのは難しくて、クライアントだけ使っているそうです。それに関連して、S式にJSONの皮をかぶせていたのが、結局クライアントで直接CSVやJSONに対応するようにしたそうです。

　ちなみに、とあるゲーム会社がl4uという商標をとっているため、名前を変更するかもという話でした。