(テキスト未定)
[topic:Haskell、並列プログラミング]
最近、 関数などの機能追加にベクトル化の実装の焦点が移ってきた り、ndp パッケージに（UArr 版ではなく [::] を使った）並列配列版のコード例が徐々に増えてきていることから、GHC の開発版ではそろそろデータ並列 Haskell でのプログラミングが可能になってきたようですね。コード例にはお馴染みの クイックソート の他、 QuickHull や Barnes-Hut 法（N 体問題） などがあります。
（並列配列を使ったプログラムを書くだけなら、 連載の第10回で説明したように 、これまでもできなくはありませんでした。ここで注目するべきは、-fvectorise オプションを使って実際にベクトル化機能を使用した例になっているところです。）
例を見てみれば分かるように、並列配列で使用するモジュールは ndp パッケージの Data.Array.Parallel.Prelude などに変わっています。ソースコード中のコメントによると最終的に Data.Array.Parallel モジュールから利用できるようにする予定のようですが、まだまだ実装しなければならないものがあるようなので、当分は Data.Array.Parallel.Prelude の方を使用することになりそうですね。GHC.PArr は、他の GHC.* モジュールと同様、ライブラリの実装に最低限必要な基本部分を提供するという扱いになるようです。
モジュールの変更の他にもう一つ気をつけなければならないのは、現在の -fvectorise オプションはデータ並列 Haskell を使ったベクトル化可能なコードとそうでないコードをきちんと見分けてくれないことです。データ並列 Haskell を使っていないコードに対して -fvectorise オプションを使用するとコンパイルに失敗したり、コンパイルは成功するもののエラー・メッセージっぽいものが出力されたりしてしまいます。なので、ベクトル化を行うコードは別のモジュールに分けておく必要があります。 メッセージを見れば分かるように type families（旧称：関連型（associated types））の絡む部分なのでまずは機能を完成させるのが先ですし 、この問題は一朝一夕には治らないでしょうね。そもそも、type families 自体まだ完成していません し。
動くとなると性能面も気になるところですが、Data.Array.Parallel.Prelude モジュールのソースコードで並列版 **UP ではなく逐次版の **U を使っていることや、 ベンチマーク を見る限り、現在のベクトル化機能ではまだ並列化まではやらないようですね。（ベンチマーク中に書いてある fusion というコメントは融合変換（fusion transformation，あるいは関数融合（function fusion））のことです。）まあ、きちんと動作するかどうかを確認する方が先なので、当然と言えば当然ですが。おそらくモジュールのソースコードの当該部分を書き換えれば並列に動くはずなので、試したい方はどうぞ。
（追記:その後 バックエンドを改良して、逐次版と並列版を切り替えて使えるようになりました 。
[topic:Haskell、並列プログラミング]
最近の GHC の開発を見ていて、データ並列 Haskell の開発が最適化機能の改良や拡充に大きな役割を果たしているのを感じます。 インライン化 や 書き換え規則（rerite rules）などの最適化のための機能が ndp の実装からのフィードバック や ndp の作者の意見などを通してどんどん改良されている のは、並列化に関心が無い人でも注目に値する流れだと思います。（もちろん、 他からのフィードバックも受けてはいます が、最近比較的目立っているのがこのあたりだということです。）
データ並列 Haskell を完成させるためには、この先 GHC の SIMD 命令などのベクトル演算や NUMA への対応が必要になっていくのでしょうけれど、残念ながら今年の Google Summer of Code（以下、GSoC）のプロジェクトにはできなかったようです。 丁度生成するコードの品質を上げるために GHC バックエンドを弄っているところ で タイミング悪かった り、 興味を持つ学生がいなかったり して。
ただ、ベクトル演算対応の方に関しては、 今年の GSoC に採択されたプロジェクト の中に GHC API の改良 や GHC の機能のプラグイン化 を目的としたものがあるので、これらを元に進められるようになるかもしれません。特にプラグイン化のアイデアを出した学生さんは、GPU での Haskell の実行に関心があるようですし。
他に データ並列 Haskell を使って物理エンジンを実装する というプロジェクトもあって、Haskell コミュニティに並列な物理エンジンの参考実装をもたらしてくれることと、使う側からのフィードバックを返してくれることに期待したいですね。
ついでにもう一つ、 Parallel profiling tools for GHC も GSoC に採択されて欲しかったのですが、slot が足りなくてあえなく断念しました。Haskell.org の抱えているメンター数的には、まだまだ余力があって、今年採択されたプロジェクトの数の二倍ぐらいは採択可能だったはずです。ですが、Haskell.org に割り当てられた slot の数の結果、魅力的ないくつかのプロジェクトをふるい落とすしかありませんでした。
Python Software Foundation など他にはもっと沢山の slot を持ったコミュニティが存在することから分かる通り、この slot 数は Haskell.org の限界ではありません。slot を増やすためには、おそらく、まずは沢山のプロジェクトのアイデアを応募して沢山の学生がこのコミュニティに関心を持っているという意思表示を行うことが大切です。ここを見ている学生の方がいたら、次に GSoC または類似のプロジェクトの募集が行われるときには物怖じせずに申し込んでみてください。動かなければ決して採択されません。一方、沢山の人が動けば、slot 数を増やして貴方が採択される可能性を上げることができるのかもしれないのですから。
あっ、あと GSoC の他に インターンをする という手もあります。こちらはやることが GHC の開発に限定されてしまいますが。
[topic:小説、感想]
ホワイト・ファング—— 狼よ、月影に瞑れ ( Amazon ) の感想を書くべきかどうか迷っていたのですが、ずっと頭の中に抱え込んでおくのも何なので書いてみることにします。
麻生俊平はいくつかのハンデを背負っている。もちろん、心体的なものではなく、作家としてのハンデだ。
一つ、スロースターターであること。シリーズものにおいて、起承転結を守り過ぎる。起はあくまで起でしかなく、1巻目はあくまで背景の紹介にとどまってしまう。その結果、1巻目だけを読んでいて面白いと感じさせることができないのは、ライトノベルと呼ばれるようになった領域で書いている作家として致命的だと言っても良い。巻を重ねることで確実に化けていくため、麻生ファンはそれを期待して読んでいくのだけど、新規ファンを獲得できないと続きを書いていけないわけで……。承を承として丁寧に書いていた VS— ヴァーサス— において、麻生ファンはこの事実を突きつけられることになった。（ 5巻目 ( Amazon ) からが本当に面白くなっていくところだったのに……。）
一つ、重苦しい展開。暗い作品にもある程度の需要はあるけれど、どうしても明るい作品に比べて人を選ぶことになる。特に普通の小説では「最後に辿りつくための試練としての暗さ＝いわゆる鬱展開」に相当するものを極めて早い段階から始めたり、数巻かけてゆっくりと足場を崩していくところを一巻の課間に一気に切り崩していったり、しかもその展開がまだ後に控えていたりするという容赦のなさがある。
一つ、あまりにも鋭利な社会批判。世の中にある批判は通常ある種のお約束の下になりたっている。それは、何が批判されるのかが予め分かっているというものだ。だからこそ、 物語中のお約束 を自ら壊してみせる作品からは衝撃を受けるし、常識という名の偏見を拭い去ってくれる専門書からは目から鱗の体験をすることができる。 新聞が（そして恐らく Web 上の多くの情報も）読まなくても批判の対象が分かると批判すべき なのは、こうした 批判におけるお約束 を乗り越えられないからだ。一方でこうしたお約束を踏み越えてくるような社会批判は、鋭利過ぎて落ち着かない。批判は読者をも射程に捉えるし、定型的でない分それに対する自己弁護をすぐには用意できないからだ。
根っからの麻生ファンは後二者の相乗効果によって彩られる麻生節こそを楽しみにしているのだけど、そうでない人にとって麻生節は麻生作品を受け入れ難くしている要素となっているのがジレンマを感じるところ。もちろん、こうした麻生節を抑えた路線の作品もあるけれど、麻生ファンとしては麻生俊平にしか書けない作品を書いて貰いたいわけで……。（そうした軽めの作品は、私は読んでいません。）
あともう一つ、往年のヒーローものを素材の一つにしつつも、お約束に従うわけではないというのも不利な部分かもしれない。もちろん麻生節によって戦うことやヒーローであることの苦悩がきちんと描かれるあたり、その作品を汚すものではないけれど……お約束に踏めばそのヒーローのファンを取り込めるにも関わらず、そうせずにファン層から距離を取ってしまうあたりは、誠実なのか照れがあるのか、それとも不器用なのか。
「ホワイト・ファング」シリーズの1作目は、そういった麻生俊平の良いところも悪いところも含めて作家性が滲み出た作品になっていると思います。読者によって賛否両論ありそうですが、間違いなく麻生節の炸裂している麻生俊平にしか書けない作品。ジャック・ロンドンの白牙 ( Amazon ) ( 白牙 のサイト )の名前を冠する（人狼ものの）この作品において、このまま白牙を踏まえていくのか、逆の方向に行き着くのか、それとも大胆に換骨奪胎してしまうのかが楽しみですね。少なくとも、そのどれにでもなりそうな要素は既に用意されているわけですし。
2作目以降きちんと加速してくれれば、後は何も言うことはありません。
[topic:Haskell]
ITpro に 本物のプログラマはHaskellを使う - 第19回 配列でデータ・アクセスの効率を上げる が掲載されました。
今回の話は前回までのテスト話とは独立したものなので、これまでの話を読んでいなくても読めると思います。一部 ST モナドに関する言及が出てきますが、次回への布石として書いているだけなので気にせずに読んでください。（どうしても気になる方は 第7回 の始めの IOモナドの表現 を読むと良いと思います。）
他のデータ構造の紹介はもう少し先になると思います。 Data.Map は今年の Google Summer of Code でトライ（trei）を使った実装などに書き換えられる そうなので、下手に早く紹介して古い情報になるよりはもう少し待った方が良さそうですし。Data.Sequence は GHC の開発版に実装されている view パターン と併せて紹介したいので。
さて、配列について説明するときに難しいのが、「これが配列だ」という特徴を述べることだと思います。C 的な配列、バイト列（byte array）、ベクタ（vector）等、配列と言っても色々なデータ構造があってなかなか特徴が一意に定まりません。今回しているようなリストとの比較話から一見「連結リスト（linked list）でないことがリストの特徴」だと言えそうですが、Richard Bird の 関数プログラミング ( Amazon ) や The Art of Computer Programming, Volume 1 ( Amazon ) には木（つまりリスト）による実装という話もあったりして、こうした考えもあえなく打ち砕かれてしまいます。そうした様々な配列的なデータ構造の表現の一つに Haskell の配列というものがあって、Haskell という言語の特徴を意識した仕様になっている、ということを理解して貰えれば幸いです。
なお、今回は 差分配列（DiffArray）、並列配列、ByteString については触れていません。これらは今回説明した配列に関する話の応用例や特殊系になっていて、下手に一緒に説明しようとすると混乱させてしまうだけになりかねないので。まずは今回の基本的な配列に親しんでください。
今日は 圏論勉強会 でした。
今回で The Haskell Programmer's Guide to the IO Monad ― Don't Panic は終了。その心を伝えるという意味で、Haskell が分かっていて圏論にちょっと興味があるという方には初心者向けの丁度良いテキストだと思いました。次のテキストはまだ決まっていませんが、こういう形で Haskell プログラミングと圏論の繋がりが見えるものが良いかもしれませんね。
初心者向けの話というと、前日の Scala勉強会@関東-1 が笹田さんのところで開催されていたこともあって、初心者向けの圏論勉強会の話が既にまわっていたようですね。笹田さんところの学生さんが研究のために興味があるということで、平日夜に週一や隔週で行うのが良いんじゃないかな、と提案してみるものの確定にはならず。他にもいくつか意見が出ていたので、それらと併せた形でもう一度笹田さん（やその学生さん）と話してみた方が良さそうですね。
