星の贈り物

GHC の Cabal 化

[topic:Haskell]

ついに待望の GHC の Cabal 化が行われました 。GHC のビルド時に自動生成される ghc_boot_platform.h に依存しています（し、開発版からは同梱されている libffi にも依存するようになった）ので楽々とは言いませんが、これで以前よりもかなり GHC の Hack がやりやすくなったと思います。

で、Cabal 化を受けて、 早速ソースコードの Haddock 化が行われました 。これまで GHC のソースコードを見たことのなかった方は、眺めているだけでも「こんな機能があったのか」というものを含めて色んな発見があると思います。とはいっても、GHC のソースコードはディレクトリという形では階層化されていましたがモジュールとしては階層化されていませんでしたし、これまで Haddock 化を意識せずにコメントをつけていたので、現在のところ Haddock を使って生成された文書 を GHC の API について解説する文書として読むには色々と不備があると思います。きちんと中身を把握したい場合には、元となった実際のソースコードや The GHC Commentary などもあわせて読んでください。

データ並列 Haskell の新しいバックエンド

[topic:Haskell、並列プログラミング]

今月の始めに、データ並列 Haskell のバックエンドが ndp パッケージから http://darcs.haskell.org/packages/dph のものに置き換わりました。

dph は ndp を dph-base　や dph-prim-interface、dph-prim-seq、dph-prim-par、dph-seq、dph-par といった複数のパッケージに再編成したものです。最終的に dph-prim-seq と dph-prim-par を使って、同じソースコードから逐次版の dph-seq と並列版の dph-par、という二つのパッケージを作成するようになっています。こうした仕組みによって、dph では逐次版と並列版のソースコードの抽象化を実現するというわけです。

（なお、これらのライブラリは専用の -Odph という最適化レベル を使ってビルドされています。）

もちろん、今回行われた変更は、この dph の特徴を生かすものになっています。（後で名前が変わるかもしれませんが暫定的に） -fdph-seq と -fdph-par という二つのオプションが加えられていて、それぞれ -fdph-seq オプションでは dph-seq パッケージを、-fdph-par オプションでは dph-par パッケージをベクトル化時に利用する ようになっています。これにより、ソースコードを書き換えなくてもオプション一つ（または -ignore-package dph-seq などを含めて二つ）で並列化するかどうかを切り替えれるようになったわけで、データ並列 Haskell を試すための環境は整いつつあると思います。

まあ、実際に試そうとすると、それ以前の GHC のビルドで苦戦することも多々あるのですが……。GHC の開発版がビルドできなくなったり、ビルドした GHC が dph を含むよう libraries ディレクトリに dph ディレクトリをまるごと突っ込んでビルドするとそれが原因でビルドに失敗したり。例えば、type families に対する改良に dph（または ndp）が追随できていなくてライブラリのビルドに失敗したり、dph-prim-interface の Haddock ドキュメントを生成しようとして失敗したり（ GHC 6.10 の Haddock 2 正式対応が待ちどうしい ）、 make binary-dist で dph から dph-seq と dph-par を作成するための仕組みを適切に取り扱ってくれなかったり……。まあ、GHC 自体のビルドに失敗するのでなければ、頑張ればビルドできなくはないと思います。どこが問題か分かったら、patch を送ってください。私もそうしていますので。

ビューティフルコード雑感

[topic:プログラミング、Haskell]

ようやくビューティフルコード ( Amazon ) ( ビューティフルコード のサポートサイト )を読み終えました。

内容の難易度はまちまち。各章でこれから語ろうとしている「美しいコード」の表れる分野について必要最低限の解説はするのですが、初心者と同じ目線で書かれたものもあれば、知っている人には納得できるように書かれているものもあるわけで。多種多様な分野の人がそれぞれの「美しいコード」について語っているので、もちろん何も知らない人であってもこれまで見聞きしたことのない色んな世界に触れることへの楽しみを味わうことができるでしょう。でも、本格的にこの本を楽しむためには、書かれている分野に対しての知識がいると思います。

訳文はこなれていて読むのに問題はないのですが、ところどころ訳語の気になる部分がありますね。「オブジェクトを XML としてシリアライズする」という意味の serialize を直列化と訳しているところとか。オブジェクトをシリアライズするためには順繰りに並べて出力しなければならないため、もともと serialize という単語をこの意味に転用した意図としてはそうなんでしょうけれど……転用されたあとの言葉の訳語としては妥当ではないと思います。……翻訳って難しい。あと、背表紙のデザインはシンプルな原書の方が好きですね。これは単に好みの問題でしかないけれど。

以下、いくつかの章の内容について感想を述べたいと思います。

7章　ビューティフル・テスト

ありがちな自動テスト・フレームワークを使えばよいという話に終るのではなく、テストをする際に気をつけるべきことがきちんと書かれていて良いですね。ランダム・テストや テストが正しいと保証される条件 の話などもしていますし、既にテストに十分馴染んでいる方もそうでない方も、これを読むことで一歩上のテスト・デバッグができるようになるのではないでしょうか？

こういう話がプログラマーにとって一般常識になってくれると良いですね。一応、連載の HUnit に対する解説 や QuickCheck に対する解説 ではこのあたりについて少し触れてみたのですが、Haskell を学ぶ中で新しく知るよりも、先に然るべき文脈の中で知っておいて Haskell での実例として見た方が何を言いたいのか納得しながら読めると思いますし。

22章　スプーン一杯の汚水で

訳者の久野先生が言っているように 手に汗握る話ですごい面白かった のですが、ほとんど図なしでこういう込み入った話をやるのは難易度が高いですね。 この間の「プ会」 の資料に丁寧な図解があったので、これを頼りに読むことで私はかなり楽に読み進めることができたのですが、他の人にとってこの章はどういう感じだったのでしょうか？

これを読んで改めて図の大切さを痛感させられました。やっぱり、並行処理の解説に図をつけることは重要だなぁ、と。

別の機会に譲ると書いている話も、いずれどこかで読んでみたいですね。今度は是非たっぷりと図の添えられている文章で。

24章　美しきかな、並列

Haskell（というか GHC）には別途並列化を目的とした機能が存在することも知っていると、原題の Beautiful concurrency を「美しきかな、並列」と訳すことについては思うところがあるのですが、より正しく「美しき並行処理」だといまいち受けが良くなさそうな気もしますね。なので仕方ないかも。（このあたりについては、手前味噌ですが連載の 第10回 Haskell で学ぶ並列プログラミング（その1） などに書いてあります。）

短い中で Haskell、そして STM の特徴的な部分を鋭く的確に語っていて、これで初めて Haskell に接するという人でも少なくとも魅力ぐらいは分かってもらえるのではないでしょうか？　ただ、例として出てくるプログラムは、選んだ例がちょっと凝ったものであるせいか、あるいは STM モナド の素晴らしさを語るためか、いずれにせよ少し技巧的過ぎるかもしれません。でも、そういう複雑な例でこそ STM モナドのデザインの素晴らしさが輝いてくるわけで、そのあたりが STM について語る場合のジレンマですね。

（STM の良さは「並行処理における根本的な要素（primitive）としての魅力」と「（普段の IO 処理とははっきり区別された専用の）モナドとしての魅力」の二つから構成されているわけで、このあたりをきちんと理解させるのはなかなか難しいと思います。STM がトランザクション・メモリ（transactional memory）のソフトウェアによる実装であることから分かるように、動作の阻止（lock や block）、トランザクション・メモリ、メッセージ通信はいずれも各々の機能を使って別の機能を再現できるものです。なので、これらを議論する上で重要なのは、「どの要素を根本的なものとすれば、ソフトウェア面では書きやすく、かつハードウェア面では効率的になるか」のはずなのですが……どうも STM 周りの議論を見聞きしていると、この視点が欠けていることが……。）

（また、上でも書いていますが、純粋に並列処理をやらせるのであれば Haskell には別の機能が用意されています。STM はあくまで並行処理用に提供された機能でしかありません。（一応、 実行時システムが、影でユーザー・スレッドの仕事を CPU に割り当ててくれます が。）もし並行処理=並列処理な形が望ましいと思っているのであれば、現在の STM を完成したものとみなして議論するのではなく、 将来のカスタマイズ可能なスレッド を念頭に置いて議論した方が良いと思います。）

なお、プログラム中に出てくる forever 関数は GHC 6.8 で型を変えて Control.Monad モジュールに取り込まれています 。

30章　世界につながる手段がボタンだけだったら

どちらかというとコードの話ではなくて、ユーザー・インターフェースの話なのですが。他にも何章かユーザー・インターフェースに関する話があるのですが、こういう話にはやっぱりプログラミング上のテクニックには出てこないまた別の面白さがあるとおもいます。

もちろん、API やフレームワークの設計、また OS などのシステムという点において接する以上、ユーザー・インターフェースが完全に疎遠なものになることはありません。また、Web プログラミングとか Ajax の隆盛などを見ていると、やっぱりユーザー・インターフェースを作りたいんだなということを感じます。だから、普段接していないことによる面白さではなくて、どちらかというと「立ち位置を変えることで頭の働かせ方の変わる面白さを味わえるのではないかな」という感じですね。

この章を読んでみて面白いと思ったら、是非ユーザー・インターフェースに関する様々な本を読み漁ってみてください。この面白さそのままに、目から鱗の体験ができると思いますよ。……ここ数年離れてたし、私も久しぶりにユーザー・インターフェースの本を読みたいなぁ。

もちろん、ここで取り上げている章以外にも沢山読んでいて面白かった章はありました。しかし、流石に面白かった全ての章の感想を書く余裕はないので、この辺で。