(テキスト未定)
[topic:Haskell]
ITpro に 本物のプログラマはHaskellを使う - 第21回 更新操作を一般化するためのSTモナド が掲載されました。
先月に引き続き 、今回は ST モナド特有の機能について解説します。先月言っていたように、前回と今回の話はもともと一回の内容であったものを二回に分割したものです。なので、もしまだ前回の記事を読んでいないのであれば、これを機に一続きの文章として読んでみてください。少しでも ST モナドの魅力に気づく方が増えれば幸いです。
また、今回のコラムでは GHC 6.10 の GC に関する情報提供してみました。 RubyKaigi 2008 の GC の話 や その後の補足 、 JVM の GC 事情 などを念頭に読んでみるとより楽しめると思います。今後いくつもの改良が加えられていくでしょうし、GC の設定をチューニングするような回でもないので、細かい説明は避けて資料へのリンクの提供を中心におこなう形になっています。現在の GC の全体像を知りたい場合には、是非リンク先の情報を調べてみてください。
今日は 圏論勉強会 でした。
RHG の逆襲（RHG 片手に Ruby 1.9 を読む集い） と重なると聞いていましたが、そちらの方は会場の都合で日にちが変更になったようですね。それにしても周知の事実ですが、こうやって二つの RHG 読書会を併記するとややこしい……。
[topic:プログラミング、Haskell]
ようやくビューティフルコード ( Amazon ) ( ビューティフルコード のサポートサイト )を読み終えました。
内容の難易度はまちまち。各章でこれから語ろうとしている「美しいコード」の表れる分野について必要最低限の解説はするのですが、初心者と同じ目線で書かれたものもあれば、知っている人には納得できるように書かれているものもあるわけで。多種多様な分野の人がそれぞれの「美しいコード」について語っているので、もちろん何も知らない人であってもこれまで見聞きしたことのない色んな世界に触れることへの楽しみを味わうことができるでしょう。でも、本格的にこの本を楽しむためには、書かれている分野に対しての知識がいると思います。
訳文はこなれていて読むのに問題はないのですが、ところどころ訳語の気になる部分がありますね。「オブジェクトを XML としてシリアライズする」という意味の serialize を直列化と訳しているところとか。オブジェクトをシリアライズするためには順繰りに並べて出力しなければならないため、もともと serialize という単語をこの意味に転用した意図としてはそうなんでしょうけれど……転用されたあとの言葉の訳語としては妥当ではないと思います。……翻訳って難しい。あと、背表紙のデザインはシンプルな原書の方が好きですね。これは単に好みの問題でしかないけれど。
以下、いくつかの章の内容について感想を述べたいと思います。
ありがちな自動テスト・フレームワークを使えばよいという話に終るのではなく、テストをする際に気をつけるべきことがきちんと書かれていて良いですね。ランダム・テストや テストが正しいと保証される条件 の話などもしていますし、既にテストに十分馴染んでいる方もそうでない方も、これを読むことで一歩上のテスト・デバッグができるようになるのではないでしょうか？
こういう話がプログラマーにとって一般常識になってくれると良いですね。一応、連載の HUnit に対する解説 や QuickCheck に対する解説 ではこのあたりについて少し触れてみたのですが、Haskell を学ぶ中で新しく知るよりも、先に然るべき文脈の中で知っておいて Haskell での実例として見た方が何を言いたいのか納得しながら読めると思いますし。
訳者の久野先生が言っているように 手に汗握る話ですごい面白かった
のですが、ほとんど図なしでこういう込み入った話をやるのは難易度が高いですね。 この間の「プ会」 の資料に丁寧な図解があったので、これを頼りにすることで私はかなり楽に読み進めることができたのですが、他の人にとってこの章はどういう感じだったのでしょうか？
というわけで、この章を読んで改めて図の大切さを痛感させられました。やっぱり、並行処理の解説に図をつけることは重要だなぁ、と。
別の機会に譲ると書いている話も、いずれどこかで読んでみたいですね。今度は是非たっぷりと図の添えられている文章で。
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 モジュールに取り込まれています 。
どちらかというとコードの話ではなくて、ユーザー・インターフェースの話なのですが。他にも何章かユーザー・インターフェースに関する話があるのですが、こういう話にはやっぱりプログラミング上のテクニックの話には出てこないまた別の面白さがあると思います。（この章は特にほとんどユーザー・インターフェースの話になっているので、そうした面白さの純度が高くなっているのが良いところですね。）
もちろん、API やフレームワークの設計、また OS などのシステムという点において接する以上、ユーザー・インターフェースが完全に疎遠なものになることはありません。また、Web プログラミングとか Ajax の隆盛などを見ていると、やっぱりユーザー・インターフェースを作りたいんだなということを感じます。だから、普段接していないことによる面白さではなくて、どちらかというと「立ち位置を変えることで頭の働かせ方の変わる面白さを味わえるのではないかな」という感じですね。
この章を読んでみて面白いと思ったら、是非ユーザー・インターフェースに関する様々な本を読み漁ってみてください。この面白さそのままに、目から鱗の体験ができると思いますよ。……ここ数年離れてたし、私も久しぶりにユーザー・インターフェースの本を読みたいなぁ。
もちろん、ここで取り上げている章以外にも沢山読んでいて面白かった章はありました。しかし、流石に面白かった全ての章の感想を書く余裕はないので、この辺で。
連載の次の回を FFI にするか MonadFix にするか迷っていて、「決まらないならいっそ両方書いてしまって、それからタイミングや反応を見て決めよう」と頑張っていたのですが……結局 MonadFix の方の記事はできませんでした。残念。FFI の記事を書いた時点で一息ついてしまったのと、ちょっと構想を広げ過ぎてそれに見合う例を作れなかったのが敗因。
まあ、次回を FFI の話にしたことで GHC 6.10 に多分入ってくる Extensible Exceptions（拡張可能なレコードによる拡張可能な例外処理） を GHC のリリースと同時期に紹介できる可能性が出てきたわけで、その意味ではこの結果も悪くは無かったのかもしれませんが。後に回したことで、もう少しじっくり MonadFix について理解を深めることもできますし。
[topic:Haskell]
ついに待望の GHC の Cabal 化が行われました 。GHC のビルド時に自動生成される ghc_boot_platform.h に依存しています（し、開発版からは同梱されている libffi にも依存するようになった）ので楽々とは言いませんが、これで以前よりもかなり GHC の Hack がやりやすくなったと思います。
で、Cabal 化を受けて、 早速ソースコードの Haddock 化が行われました 。これまで GHC のソースコードを見たことのなかった方は、眺めているだけでも「こんな機能があったのか」というものを含めて色んな発見があると思います。とはいっても、GHC のソースコードはディレクトリという形では階層化されていましたがモジュールとしては階層化されていませんでしたし、これまで Haddock 化を意識せずにコメントをつけていたので、現在のところ Haddock を使って生成された文書 を GHC の API について解説する文書として読むには色々と不備があると思います。きちんと中身を把握したい場合には、元となった実際のソースコードや The GHC Commentary などもあわせて読んでください。
[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 を送ってください。私もそうしていますので。
あろはさんが来る ということで、 LL Future のプログラム概要 を確かめてみたのですが、今年は Language Update はないようですね。去年 Haskell が参加しなかった分、二年間の変化について語る場が欲しかったのですが……残念。まあ、本当に様々な言語が集まっているおかげで十分な発表時間が取れていませんでしたし、仕方ありませんね。
パネルディスカッションのテーマとなっている言語の未来は、ブラウザがどうのこうのよりもカスタマイズ可能な言語処理系にあると思うのですが、どうなんでしょうか？ LLVM でプラグインが使える （ GC プラグインの作り方 ） だけではなく、 Agda でもプラグインが使えた り、 GHC でもプラグインを導入しようとしている ように、少し周りを見渡すだけでも言語処理系にプラグイン機構を取り入れる流れがあるようなのですが。また、 GHC ではカスタマイズ可能なスレッドが提案されています し、（有名なところでは）JVM を含めていくつかの処理系では実行時の GC の戦略を変更できますし、他の部分でも色々と言語（および言語処理系）の機能を用途に合わせてカスタマイズできるようにする流れがあるように思えます。
[topic:小説、感想]
31日かつ木曜日という発売日設定が悪いのか（翌日発売扱いになっているのかも？）、書店を回ってもなかなか見つからなかったのですが、 ホワイト・ファング—— 孤狼の唄、今は絶え ( Amazon ) をどうにか確保して読みました。
媚びないなぁ、一言で感想を書くとすればそんなところでしょうか？ やりようによっては過去話をもっとお涙頂戴ものとして描くことも可能だったと思います。そのため、副題として最初に出てきたのは銀嶺に哭くだったのでしょう。しかし、物語られるべきは現在で、過去を書くことの役割は現在の瞳の考えや行動が何によって成り立ったものであるかを示すためのもの。また、過去の問題に向き合わせ、現在克服するべき課題との繋がりを示すためのもの。だからこそ、過去話を安易な共感を得るための形式に埋めることなく、それらをきっちりと描くことを目的としたものにしてきたのでしょう。
それにしても……予想してたとはいえ、あまりにも公的権力がえげつないものとして描写されていることに、思わず作者に対する心配を覚えますね。VS— ヴァーサス—さえ、VS さえ打ち切られずにしっかり最後まで描いてくれれば、左翼とかの烙印を押されずに……たとえそういう偏見の目で見られたとしても反証となる作品を示せたのに、というような心配を。（一巻目の段階ではそうやって心配している人のことを杞憂だといって一笑に付することができたですが、二巻目にして更に苛烈に描写されるとなると。）また、このえげつなさに、読者が引いてしまうのではないかと。
でも、そういう部分を乗り越えて無事最後まで読みきれば、納得すると思います。ああっ、なるほど、このためにあえてそこまで人と人の作った社会の醜さや過ちを描く必要があったのか、と。 麻生俊平という作家性 を最大限生かそうとして出てきた話なのだと。過去作品で指摘した欺瞞に陥らないために、テーマに対して誠実に向き合うために避けては通れない道なのだと。二巻かけて整えられた舞台、そこで繰り広げられるこれからの物語に期待が膨らみます。これはうまくいけば傑作になりそうですね。……ただ、そこまでが重過ぎて、読者がついてきてくれる（打ち切りにならない）かどうかが心配なんですが。
あと、今後も格好良い大人の人が出てくることに期待。汚い世の中に「それでもこういう格好良い大人がいる」ということを示すのは、醜い現実と対比する意味でも、主人公達の足場を支えていく意味でも重要だと思いますし……何より、この巻で黒手由美香が魅力的な大人として描かれていたからですが。
