Monad tutorial
- 1. 函数プログラミングの集い2011 チュートリゕル 「モナドについて」 株式会社 Preffered Infrastructure 田中 英行 tanaka.hideyuki@gmail.com
- 2. 自己紹介 • 田中英行 (@tanakh, id:tanakh) • 株式会社 Preferred Infrastructure (PFI) 勤務 – 検索エンジンのゕルゴリズムとか作ってます • Haskell (2004～) • C++ (1998～) • BASIC (1992～) • プログラミングコンテスト愛好家 – ICPC, ICFPC, CodeJam, TopCoder, …
- 3. 本日の概要 • モナドとは？ • モナドの使い方 – モナドのセマンテゖクス – 典型的なモナドの例 – Haskellでのモナド • モナドの作り方 – モナドのンスタンスに – モナド変換子
- 5. モナドとは何か？ • 非常に難しい質問です • 既に数多くの人がそれに答えようとして います – そして各々が一見全く違う主張をしている
- 6. 幾つかの例
- 7. 『モナドは象である』
- 10. 『コンベゕのゕナロジー』 from “All About Monads”
- 11. いろいろありますが… • 結局モナドとはなんなのか？ モナドの力の秘密、 いつか解き明かしてみたいな…
- 12. モナドについての疑問 • 疑問にもいろいろある – モナドとは何か？ – 何の役に立つのか？ – なぜモナドなのか？ モナドがもてはやされるのか？ • ゕローとモナド、どうして差がついた… • それぞれについて、私なりの見解
- 14. 抽象的な話
- 15. パラダム？ • プログラミングパラダム – 手続き型 – 関数型 – 論理型 – オブジェクト志向 – モナデゖック（？） • ここじゃない
- 16. モナドとは手続き型パラダムの 再定義である • プログラミングパラダム – 手続き型 • モナデゖック – 関数型 – 論理型 – オブジェクト志向
- 17. 意味的側面からの モナドのメタフゔー • モナドは『プログラマブルセミコロン』 である
- 18. Programmable Semicolon • Real World Haskell より
- 19. 手続き型言語と構造化定理 • プログラムは、「順次・反復・分岐」の 基本的な構造の組み合わせによって記述 できる • これらはモナドへ直接的にマッピングで きる
- 20. それで、何が嬉しいの？ • 分岐のセマンテゖクス書き換え • 反復のセマンテゖクス書き換え – そういうことができる言語は過去にはあった • 逐次のセマンテゖクス書き換え – かつて無いもの（…の様な気がします）！
- 21. 逐次のセマンテゖクス • およそほとんどの手続き型言語では、 セミコロンの意味は変えられない – 空気のような存在 • セミコロンの意味を変えることの意義が 伝統的に見逃されて来たのではないか？ int main() { main = foo(); bar(); foo >> bar }
- 22. 継続との関係 • モナドは継続(continuation)の一般化とも考 えることができます • 継続＝各セミコロンにおけるプログラム の状態 • モナドはセミコロンを記述するわけなの で、その状態を取り出すことは簡単 – 実際に継続モナドというものがあります
- 23. セミコロンをいじることにより 可能になること • 普通のプログラムを非決定計算に変える • 普通のプログラムにエラーハンドリング を(プログラムを書き換えずに)追加する • 普通のプログラムに暗黙の状態を導入す る
- 24. コンテクスト • 具体的なモナドに対して、それが計算に 付加価値を与えます。それを（計算の） コンテクストと呼ぶことにします – つまり、モナドというのはコンテクスト付き の計算ということができる • 例えば… – monad:リストモナド → ctx:非決定性 – monad:Stateモナド → ctx:mutableな状態 – etc …
- 25. それぞれにそういうプログラムを 書けばいいんじゃないんですか？ • コンテクストごとに異なる記法 • コンテクストごとに異なるプログラム • コンテクストごとに異なる語彙 ・・・ 抽象化の欠如
- 26. コンテクストの抽象化 • 共通のゕルゴリズムの記述 • 共通のコード片の抽象化 よりメタレベルの抽象化へ
- 27. 床下配線のゕナロジー • モナドによるセミコロンの抽象化は 床下配線と例えられることも – 見えないところを書き換える
- 28. 少し具体的な話
- 29. 例 • N-クーン問題 – Int が与えられて解を返す – 解とはなんぞや？ • 全解列挙 • どれか一つを見つける • 一番いい解を頼む – いろいろ考えうる
- 30. N-Queen問題 • モナデゖックに書くと、これらを統一的 に扱える – 解の列挙のストラテジをモナドとして記述 – 問題を解くゕルゴリズムからの分離
- 31. 前半まとめ • モナドとは何なのか？ – 計算コンテクストの抽象化である • なんでそれが嬉しいの？ – 具体的なコンテクストに依存しないコードを 書ける – 抽象化したものを具体的なコードにできる • なぜモナドなの？ – モナドは構造化定理に必要な要素を自然に記 述できて、なおかつ簡潔であるから
- 32. 三行で言うと • モナドは関数レベルで • メタプログラミング • するためのものです (´･_･`)えっ…？
- 33. How to use Monads モナド入門・モナドの使い方
- 34. 実装レベルのお話
- 35. モナドとは • “ある特定の方法”で組み合わせることので きる計算のことをまとめて、 モナド と呼びます。
- 36. ちなみに • 組み合わせ可能な計算はモナドだけではあり ません – いろいろな抽象化におけるそれが存在 • 例えば、 – 関数 （関数合成） – フゔンクタ （関手） – ゕプリカテゖブ・フゔンクタ – ゕロー – Iteratee – etc…
- 39. モナドになっている標準データ型 • 標準データ型の中にもモナドがある – リスト – Maybe – Either – IO
- 40. モナド則の必要性 • モナド則は、モナドを安全に組み合わせ るのに必要 – これらの挙動が同じでなければ、組み合わせ 方によって意味が変わるということになる
- 41. Haskellのdo記法 • Haskellではモナドを非常によく使うので、 専用の構文糖衣が用意されています
- 42. 高度なモナドの使い方
- 43. リストモナド • リストはモナドにできる • リストは非決定 計算のコンテクスト と捉えることが できる
- 46. IOモナドの功罪 • モナドに関するよくある誤解 – モナドってpurely functional languageでIOする ためにあるんでしょ？ • モナドはIOのためにあるのではありません • モナドはIOのためにあるのではありません – 大事なことなので
- 47. モナド則 • すべてのモナドは次のモナド則を満たす ”べき”である – 満たす保証をするのはプログラマの責任 – あえて満たさなくても良い
- 48. モナド変換子(Monad Transformers) • モナドとモナドを組み合わせるもの – (cf. 計算と計算を組み合わせるものがモナド)
- 49. 動機 • 複数の計算コンテクストを合成したい – 失敗するかもしれないIO計算 – エラーハンドリングできるパーザー – etc, …
- 50. MTL (Monad Transformer Library) • 標準のモナドラブラリ – Preludeのモナドを大幅強化 • これらのものを含む – 幾つかの標準的なモナド – これらのモナドを合成するための モナド変換子(Monad Transformers)
- 51. MTLに含まれるモナド • Monad.Cont （継続） • Monad.Reader （ReadOnly状態） • Monad.Writer （ログ出力） • Monad.State （Mutable状態） • Monad.List （非決定計算） • Monad.Error （エラーハンドリング） • これに加え、それぞれのモナド変換子版
- 52. モナド変換子 • 2つのモナドを合成するためのもの • 例えばStateモナドの場合： – StateT s m a • モナド変換子版Stateモナド • State s a と比べて、mというパラメータが追加 • mに合成したいモナドを代入 – StateT s IO a • IOモナドを内包したStateモナド • IOモナドの操作とStateモナドの操作が両方できる
- 53. 持ち上げ(lift) • StateT s IO の例 – StateT s IO の中でIOを行うには、持ち上げ(lift) を行う必要がある（型が合わないので）
- 54. モナドクラス • 例えばIOを行うだけの計算 • これは、StateT s IO 以外のモナドでも使え て欲しい – ErrorT err IO – ReaderT s IO –…
- 55. MonadIOクラス • そのために、IOをliftできるクラス全体を抽象 化したMonadIOクラスを定義 • 先のコードは次のような型に • StateT s IO などをMonadIOのンスタンスに すれば使用可能に。
- 56. 一般の持ち上げ • モナド変換子に渡されるモナドはIOだけで はない – ネストする場合もある • 一般ケースのために、MonadTransという クラスが用意されている – 内側のモナド外側のモナドに持ち上げること ができる
- 57. 中盤まとめ • モナドとは >>= と return の2つの演算が定 義されたもの • 標準データ型の多くのものがモナドに なっている • mtlというモナド変換子ラブラリがある • モナド変換子を用いてモナドを組み合わ せる • モナド持ち上げで型の異なるモナドを張 り合わせる
- 58. Advanced Topics
- 59. monad-control (1) • liftの逆をするもの • 動機 – Haskellの例外ハンドリング機構はIOモナド ベース – 渡せるものがIO固定 • MonadIO に対しても例外ハンドルしたい
- 60. monad-control (2) • MonadIOに対して一般化 • それを行えるようにするために、 MonadControlIOというクラスを用意
- 61. モナドいろいろ • 近年実に様々なラブラリがモナデゖッ クラブラリとして提供されるようにな りました • それらの一部を紹介していきたいと思い ます
- 62. MonadPar • 並列計算を記述するためのモナド – `par`, `seq` などをモナド化したもの
- 63. Parser • パーザいろいろ – Parsec, Attoparsec, trifecta
- 64. WebApp • WAI, Yesod, Snap, CGI, …
- 66. How to design your monads モナドの作り方
- 67. モナドを設計するにあたって • 自分のラブラリが、モナドとして抽象 化できることに気づいたとします • しかし、モナドの作り方を間違うと、非 常に使い勝手の悪いものができてしまい ます – 使い勝手のよいモナドの実装には気をつける べきことが沢山あります • ここまで紹介したことはすべて理解して おくことが望ましいです
- 68. 1) 既存のモナドが利用できないか • 実際のところ、mtlに含まれるモナドで、 ほとんどのケースはカバーされます • 作りたい計算が、mtlにあるモナドの組み 合わせで実現できないかまず検討するべ きです
- 69. 2) モナド変換子版を用意する • いざモナドを作るとなったら、(原理的に) 可能なのであれば、モナド変換子版を必 ず用意しましょう – モナド変換子にはHogeTと、末尾に大文字Tを つけるのが慣習です • 非モナド変換子版は、モナド変換子版に Identityモナドを代入したものにします – 実装を重複させてはいけません
- 70. MonadIOクラスのンスタンスにする • あなたのモナドをMonadIOのンスタンス にしておくのはとても良いことです • あなたのモナドを利用するすべての場所 でIOを行うことができるようになります • MonadIOを用意しておくのはモナドによっ てIOを行うHaskellにとっては極めて重要な ことです
- 71. ※ IOモナドについて(1) • IOモナドは、Haskellのプログラムの中では外 すことのできないモナドです – unsafePerformIO などを除いて • その結果、IOを呼ぶコードはそれ自身がIOを 行わなくても、IOモナドにする必要がありま す • Haskellによくある批判として、まともなプロ グラムを書いているとほとんどすべての関数 の型がIOになる、というのがあります – IOモナドは感染するとか言われます
- 72. ※ IOモナドについて(2) • そこでMonadIOの出番です • IOが必要なコンテクストについてのみ、 MonadIOを要求させておけば良くなります • Pureなモナドに関しては、具体的な型が決 定するに従って、自動で持ち上げられる ことになります • つまり、PureなコードとIOのコードのオー バーロードが可能になるということです
- 73. 3) MonadControlIOの ンスタンスにする • あなたのモナドが例外を正しく扱えるよ うにするために、MonadControlIOのンス タンスにしましょう – これがないと bracket などが正しく後処理でき ません
- 74. 4) MonadTransのンスタンスにする • あなたのモナド変換子が、他のモナドを 自動多段持ち上げ可能になるように(可能 であれば)必ず、MonadTransのンスタン スにしましょう
- 75. 5) Functor, Applicative のンスタンスにする • Applicativeスタルというものがあります – http://d.hatena.ne.jp/kazu-yamamoto/20101211/1292021817 – などを参照 • あなたのモナドをFunctor, Applicativeの ンスタンスにすると、使い勝手が大幅に 向上します • 必ずこれらのンスタンスにしましょう – Monadのンスタンスは必ずFunctor及び Applicativeのンスタンスにできます
- 76. 6) 必要に応じて、その他 • その他のモナドクラスのンスタンスに します – エラーハンドリングを付けたいなら、 MonadError – 失敗に対する代替を与えたいときには、 Alternative
- 77. ※ Alternativeクラスについて • m1 <|> m2 なる演算子が定義されている • m1が失敗したとき、m2の結果 • Alternativeの任意のンスタンスに対して – many p – pを失敗するまで繰り返し – some p – pを失敗するまで1回以上繰り返し – optional p – p が失敗したらNothing成功したら Just aを返す – これらを定義することができる
- 78. GenericNewtypeDeriving • 自分のモナドをこれらすべてのンスタ ンスにするのは骨の折れる作業です • モナドがnewtypeの時、これをderiving で 済ませることができます – -XGenericNewtypeDeriving 言語拡張
- 79. 後半まとめ • モナドを作るにあたって – MTLのモナドの組み合わせで実現できないか 考える – いろいろなクラスのンスタンスにしておく – モナド以外の有用なクラスが標準にあるので それのンスタンスにもする