Haskell Day 2012に行ってきました

Haskellについてもっと知りたい! と思い、Haskell Day 2012に行ってきました。

すごいHaskellたのしく学ぼう!

すごいHaskellたのしく学ぼう!

幅広く、開発環境の設定から応用まで、自分のHaskell力が圧倒的に不足しているせいで理解できたことの方が少ないですが、入門書を読み終わった後の道しるべが見えました。
それぞれの発表で印象に残った点と、簡単な可能を交えて今日の発表内容を紹介します。

すごいHaskell楽しく学ぼう裏話

スライド - http://tanakh.jp/pub/haskell-day-2012-05-27.html#1


没案:「Haskellやらないか」「みんなでHaskellレーニング」「Asパターンぺろぺろ」
Haskell初心者レビュアーを募集して、分かりづらいところを重点的に補足。
画像のネタと英語のジョークがあるので、日本語訳だと何でその絵なのかが分からないかも。
英語自体はこちらからタダで読める。 - http://learnyouahaskell.com/

スタート Haskell 2 と Haskell の歴史

Escape From the Ivory Tower: The Haskell Journey, From 1990 to 2011 で使われたスライドを元にしたお話。


Haskellはあまり使われていないように見えるが、よく話されている*1
DSL/並列・並行プログラミングがHaskellのKiller Contents。
『全力で成功を回避してきた経歴がある』→下位互換とかが無いとユーザがうるさい*2
Haskellはアイデアを試すには十分多く、寛容で変化していけるユーザ層に対してマッチする言語。

vim の開発環境

スライド - http://www.slideshare.net/eagletmt/vim-13092108


vimを使ったHaskell開発環境設定のお話。
まだおもちゃレベルしか書いてないからあまり使ってないけど、まともに開発をしていくようになると必須かな。

QuickFixに各種のメッセージ(エラー・警告・型など)を表示。
vimのコマンドによるエラー間の移動や、保存をトリガにしたエラーチェックなどもある。
cabal install ghc-mod があらかじめ必要。

キーワード補間。neocomplcacheというのも。
cabal install ghc-mod があらかじめ必要。

  • unite-haddock: ドキュメントを開く

Hoogleコマンドをローカル環境に導入でき、それから引いたりできるので便利。

Emacsとglossでお絵描きしてみるよ

スライド - http://www.slideshare.net/master_q/emacsgloss


ghc-modをとりあえず入れよう(cabal install ghc-mod)。
Debian sid だと All-in-oneで便利だよ!とのこと。
glossという描画ライブラリ(?)かな。
http://hackage.haskell.org/packages/archive/gloss/1.0.0.0/doc/html/Graphics-Gloss.html
しかしHoogle見ても思うけど、Haskellのリファレンスは分かりやすい気がする。
物理演算サンプル、ゲームも作れるなど、かなり実用性高そうだなーという印象。

cabal の使い方と dependency hell

これまでにも何度か出てきたcabalの説明。
cabal: 必要となるパッケージを全て含めてインストールしてくれるツール。

cabal install PACKAGE_NAME

うまくいってる時はいいのだが……複数のパッケージのバージョン依存関係を解決できない場合がある。
パッケージが巨大になると、バックトラックの数が多すぎて諦めてしまう(バックトラック数を指定するオプションもある)。
一番最後に入力したものが最優先となり、古いやつを壊してしまう(可能性がある)。
Debian sid だとパッケージシステムが依存関係を壊さないように保ってくれる。
よっぽど使い込まないと、cabalには悩まされないらしいので、依存関係に悩むようになればHaskellを使い込んでいる証拠?
cabalのバージョンアップで、このあたりの問題を解決する方向には動いているらしい。


ちなみに、この依存関係解決の問題ってNP困難*3のクラスに属するみたいだけれど、
有向グラフで表現されていたので、もしかしたらグラフに定式化された問題として何か名前があるのかなーと思った。
単なる興味本位ですが、何か情報持っている方教えてくれるとうれしいです。

Yesod の紹介とライブコーディング

スライド - http://www.slideshare.net/ssuser6c06ba/20120527yesod


Yesod自体は旧約聖書生命の樹(セフィロトの樹)の第9セフィラが名前の元なのかな?
システムを構築する話を聞いて、Haskell製サーバであるMightyが具体的なHaskellの利用例の1つとして気になった。
SSLを使ってないってことだけど、基本全部SSLApacheで受けて、全部Mightyに流す感じで処理していくのかな?


ライブコーディングを見て、まだHaskellのdoとか$とかに不慣れなので、そのあたりを調べつつ追ってたけれど、
見ていた感じ、使用するキーワードがやりたいことと直結していて読み解けさえすれば分かりやすそう。
Yesod ExitFailure 11 ははまりやすいキーワードで、cabalの設定に追加してやらなければいけないとのこと。

Haskell status update

5/30リリースのGHCiやcabalの新機能やモナド内包表記のお話とか。
さすがに現行の仕様を理解していないと、あまりうれしさが実感しにくいけど、今も変化し続けていることがよくわかりました。
モジュールやパッケージに型とはまたすごい発想だな。
……と思ったけど、そういえばもうOCamlだとモジュールを型として扱うっていう話があった気がする。

Haskell で Behavior Driven Development

スライド - http://mew.org/~kazu/material/2012-bdd.pdf


Haskellではコンパイルが通れば大体思い通りに動く!』
これはすごく同意。テストはあまり書きたくないし、書かないに越したことはないし*4
ただ一方で、0で割るなどの問題や、仕様のバグは見いだせないので、値に関するテストがないと、そのあたりの見落としをする可能性が高い。
そのあたりを「ある別の処理と等価な性質を持っている事」でテストするという観点は分かりやすかった。
それを実行するために、Quickcheck, haddock, Hspecなどのツールを使うことで、よりHaskellerがテストをしたいと思わせられる環境が作れる。

見た目は指数、中身は線形。〜GTAプログラミング〜

論文 - http://www.keisu.t.u-tokyo.ac.jp/research/techrep/data/2011/METR11-01.pdf
スライド - https://bitbucket.org/emoto/gtalib/src のslide以下のpdfファイル


『見た目は指数コストのプログラムを書いても、中身は線形コストで効率的に計算をしてくれる』
計算量とか研究でかじってたんで、このあたりの話を聞くとわくわくします。

cabal install GTALib
http://hackage.haskell.org/package/GTALib

GTAはそれぞれGenerator, Tester, Aggregatorであり、

  • Generatorで必要な解候補を全生成。
  • Testerで不必要なものを削除。
  • Aggregatorで残りから解を生成。

という個別の機能を組み合わせて問題を解く。
問題を解くためにはこの枠組みを生成する。


今回のナップサック問題の例では、変換を行うと自動的に動的計画法による方法と同じ手順を再構成してくれる。
とはいえ、やはりコアはTesterによる絞り込みが適切に効かないとあまり効果が無い模様。
久々に学会みたいな発表聞いたけど、やっぱりこういうのは分からなくても好き。楽しいなぁ。
Haskellでの学術的分野の応用はもっと聞いてみたい分野ですね。

Haskell で DB 触ってみた

スライド - http://www.slideshare.net/rf0444/haskellday-rf


Haskellで永続化機構を使い始めるまでに必要な最初の設定の紹介。
コードも短く、JavaのO/Rマッパーをセットアップするよりもcabal installさえできれば、こっちの方が楽かも。
最初の頃は「Haskellって純粋だから副作用使いづらい」的なイメージがあったけど、
IOを包み込んだライブラリが提供されていることで、そのあたりを気にすることなくかなり気軽に使えるようになっている現状が分かりました。

参照等価性とはなんだったのか

参照等価性とは - http://msakai.jp/d/?date=20090705#p01
つよいせいやくすごくつよい。(ゴンさんのThis way...定理により証明できる。)
適切な責任(IO/GUI)の切り分けを型・設計のレベルで適切に。
値に範囲の制限をかけたい場合、範囲が大きいとHaskellでは少し難しいか?
(Templete Haskellで定数を無理やり生成することで対応できなくもなさそう。)
依存型(=型と制約の組)を取り入れる方向に進んでいるそうなので、それが導入されると変わるかも?

最後に

今回はお話を聞かせてもらうだけの形になってしまいましたが、自分もすごいHaskellたのしく学んで行きたいと思います。
Haskell Day 2012 の準備をしてくれた皆様、発表者の皆様、このような素晴らしいイベントをありがとうございました。


※今回の記事を書くにあたって、Twitterハッシュタグ#hsdayに流れてきたツイートの内容を参考にしました。発信者の方々にお礼申し上げます。

追記セクション

@ringtaroさんがHaskell Day 2012中の関連ツイートをTogetterにまとめてくださったようです。
Haskell Day 2012 - http://togetter.com/li/310866

*1:1位がC++だったのは現在の自分のTLでも変わらないなぁと思ったり

*2:Javaとか

*3:経路があるかを判定するだけの「判定問題」である場合はNP完全

*4:あくまで、書く場合と書かない場合で同じ結果が得られるなら、という文脈での発言であることに注意