Recommended
More Related Content
What's hot
What's hot (20)
More from Kousuke Ruichi
Recently uploaded
Recently uploaded (11)
Haskell Day2012 - 参照透過性とは何だったのか
- 1. 参照透過性とは 何だったのか version 0.0.1 ruicc
- 2. はじめに • つっこみ所が満載のスライドです。 • お手柔らかにお願いします。 • 長いです。 • 巻きます。
- 3. 自己紹介 • @ruicc • Ruichi Kousuke • 好きな作曲家：A. Bruckner • 好きなバイオリニスト：Hilary Hahn • 好きな言語：Haskell • 爆発すればいい言語：PHP
- 4. はじめに • にあふれる • 「Haskellこわい」 • 「関数型こわい」 • 「なごやこわい」 （いやこれは関係ないけど..
- 6. 昔の偉い人は言いました 巨人の肩の上に立つ Bernard of Chartres
- 8. Haskellどう見える • 使った事無い人 • 巨人を見上げる ➡こわい • 使った事ある人 • 巨人の肩の上に立つ ➡頼もしい
- 9. ぴったりだ！
- 10. 巨人の肩の上に立とう！
- 11. このスライドの範囲 • 強い型付 • 静的型付 • 参照透過性
- 12. 強い静的型付け言語 Java Haskell Scala C# OCaml C++ F# Clean SML# D
- 13. オブジェクト指向 オブジェクト指向言語 Java Haskell Scala C# OCaml C++ F# Clean SML# D
- 14. みんな大好き強い静的型付関数型 関数型言語 Java Haskell Scala C# OCaml C++ F# Clean SML# D
- 15. よくある認識 オブジェクト指向言語 関数型言語 Java Haskell Scala C# OCaml C++ F# Clean SML# D
- 16. このスライドの範囲 純粋関数型言語 Java Haskell Scala C# OCaml C++ F# Clean SML# D
- 17. 交わらない何か オブジェクト指向言語 純粋関数型言語 Java Haskell Scala C# OCaml C++ F# Clean SML# D
- 18. Note: OOPLと純粋性 • オブジェクト指向言語に純粋性は相容れない？ • メソッドはメンバの参照が必要 • メソッドを純粋には出来ない • オブジェクト単位で見たら純粋性？は確保出来る • コンストラクタ以外の情報を用いない？？
- 19. 純粋関数型言語とは • Purely Functional Programming Language • （他パラダイムが混じらない純粋な 関数型） の言語 ←まちがい！ • （純粋 && 実用的）な言語 ←せいかい！ • 参照透過性を持った言語
- 20. 参照透過性？ • Referencial Transparency • 式や言語の性質（以降言語の性質として用いる） • 返り値が引数のみによって決まる性質 • 引数が同じなら返り値は常に同じ
- 21. つまり？ • 非常に厳しい制約に見える • （実際厳しい）
- 22. 参考：念能力 • 強い制約 → 強い力 • This way.
- 24. えっ...
- 26. いやいやいや
- 27. そうじゃないだろ
- 29. 目次 • 型と参照透過性 • 設計と参照透過性 • 抽象化と参照透過性 • テストと参照透過性
- 31. 関数と型 TypeA f TypeB • f :: TypeA -> TypeB • どう読める？ • fは、TypeAを引数にとってTypeBを返す関数 ...まあ間違ってはないけど。
- 32. 関数と型 TypeA f TypeB • f :: TypeA -> TypeB • どう読める？ • fは、TypeBを返すために、引数TypeA以外の情 報を一切使わない関数
- 33. 型2 • g :: (Monad m) => TypeA -> m TypeB • どう読む？
- 34. えーと、モナドって。 • モナドの定義は省略。 • モナドとはコンテクスト、計算、...いろんな呼び名 • 抽象的すぎて一言で表しづらい • ここではコンテクスト／文脈とする • 個々のモナドが提供するいくつかの関数 • コンテクストから情報がとれる • コンテクストに影響を与える • モナドはもっと一般的な概念だが、説明のため以下モナド といったら状態系のモナドを指すとする
- 35. 例えば状態系のモナド • g :: (Monad m) => TypeA -> m TypeB • イメージ図 Monad m TypeA f m TypeB Context
- 36. 例えば状態系のモナド • g :: (Monad m) => TypeA -> m TypeB • 引数はTypeA 引数 Monad m TypeA f m TypeB Context
- 37. 例えば状態系のモナド • g :: (Monad m) => TypeA -> m TypeB • コンテクスト／文脈は背後に存在するイメージ コンテクスト Monad m （状態系） TypeA f m TypeB Context
- 38. 例えば状態系のモナド • g :: (Monad m) => TypeA -> m TypeB • 返り値は文脈情報付きで表される 返り値 Monad m （文脈情報付き） TypeA f m TypeB Context
- 39. 例えば状態系のモナド • g :: (Monad m) => TypeA -> m TypeB • コンテクストに状態が保持されている Monad m TypeA f m TypeB モナドが保持 する状態 Context
- 40. 例えば状態系のモナド • g :: (Monad m) => TypeA -> m TypeB • コンテクストの状態と相互作用出来る • 相互作用のための関数が大抵存在 Monad m TypeA f m TypeB 状態との 相互作用 Context
- 41. 例えば状態系のモナド • g :: (Monad m) => TypeA -> m TypeB • モナド（状態系）はそんな感じのイメージ Monad m TypeA f m TypeB Context
- 42. 例えば状態系のモナド • 個々のモナド（状態系）を見てみる • Reader • Writer • State • IO
- 43. Readerモナド • Readerモナド • ReadOnlyの値をコンテクストに持つ • f :: (MonadReader m) => TypeA -> m TypeB MonadReader m TypeA f m TypeB ReadOnly!! Config情報 Config
- 44. Writerモナド • Writerモナド • WriteOnlyの値をコンテクストに持つ • f :: (MonadWriter m) => TypeA -> m TypeB MonadWriter m TypeA f m TypeB WriteOnly!! Log情報 Log
- 45. Stateモナド • Stateモナド • 書き換え可能な値をコンテクストに持つ • f :: (MonadState m) => TypeA -> m TypeB MonadState m TypeA f m TypeB Read / Write 所謂「状態」 可能 State
- 46. IOモナド • IOモナド • 外界とやりとり出来るぜー • f :: TypeA -> IO TypeB IO TypeA f IO TypeB 副作用！ 外部の世界！ World
- 47. モナド変換子 • モナドとモナド変換子からモナドを作る • コンテクスト同士を組み合わせる TypeA f m TypeB State StateT モナド変換子 Config ReaderT モナド変換子 World IO モナド
- 48. モナド変換子 • モナドとモナド変換子からモナドを作る • 組み合わせた結果もモナドになる TypeA f m TypeB State 組み合わせた StateT 結果もモナド Config ReaderT World IO
- 49. モナド変換子 • モナドとモナド変換子からモナドを作る • それぞれの文脈と相互作用出来る TypeA f m TypeB それぞれの文脈と State 相互作用可能 StateT Config ReaderT World IO
- 50. 設計観点から見たモナド • モナドとはコンテクストの部品 • 既存のコンテクストを組み合わせて目的に適した コンテクストを作る TypeA f m TypeB State StateT Config ReaderT World IO
- 52. もう一度、型2 • g :: (Monad m) => TypeA -> m TypeB • どう読む？ • 引数TypeAに加え、コンテクストmと相互作用をする Monad m TypeA g m TypeB Context
- 53. もう一度、型2 • g :: (Monad m) => TypeA -> m TypeB • どう読む？ • gの返り値であるコンテクストm上の計算結果 TypeBは、 • 引数TypeAとコンテクストmから取得できる情報 以外の情報を一切使わない
- 54. つまり？ • 情報の依存関係が明確に現れる TypeA f TypeB ※fの結果 TypeBはTypeAにのみ依存する TypeA g m TypeB Context ※ gの結果TypeBはTypeAとコンテクストmに依存する
- 58. 設計とは何か • 責務の割り当て • 参照出来る情報の制限 • 影響を与える範囲の制限
- 59. 設計とは何か • アーキテクチャ • 責務ごとに分割 • レイヤー • 下位レイヤーに依存、上位レイヤーと疎 • モジュール • オブジェクトを責務ごとに分類 • オブジェクト • 扱う情報、責務ごとに分割
- 60. 参照出来る情報の制限 • f :: TypeA -> TypeB 参照情報は 引数のみ TypeA f TypeB • g :: (Monad m) => TypeA -> m TypeB TypeA g m TypeB 参照情報1 Context 参照情報2
- 61. 影響を与える範囲の制限 外部への影響は • f :: TypeA -> TypeB 一切無い！ TypeA f TypeB • g :: (Monad m) => TypeA -> m TypeB TypeA g m TypeB Context 影響を与える範囲 はここだけ！
- 62. 副作用の明示 • h :: TypeA -> IO TypeB TypeA g IO TypeB World 外界とのやり取りは 副作用！
- 63. どういうこと？ • 純粋関数型言語の「型」はUMLのクラス図以上の 言及力を持っている • 純粋関数型言語では「型」を決める事が「設計」 • 「設計」がソースコードについてくる！ • 実装から乖離されることなく保守され続ける！
- 64. モジュール同士の疎結合 • モジュール化 • 疎結合が良いって言うよねー • 純粋函数型言語では関数同士全てが完全に疎 • 依存関係が絡まったスパゲッティにならない！
- 65. モジュール内の密結合 • かんたん！ • モジュール内部でのみ扱う型をつくる • モナドでコンテクストを特定させる
- 68. 日々のタスク（理想） • ドメインに適した抽象度を持つ機能が既にあって、 • それらを適切に特殊化して、 • 直交した機能同士を組み合わせて、 • パフォーマンスに問題なく、 • バグは出ない
- 69. 日々のタスク（理想） • ドメインに適した抽象度を持つ機能が既にあって、 • それらを適切に特殊化して、 • 直交した機能同士を組み合わせて、 • パフォーマンスに問題なく、 • バグは出ない
- 70. 日々のタスク（理想）の為に • ドメインに合わせてほどよく抽象された機能を作 る必要がある • 抽象力が要る • バグ無く組み合わせられる必要がある • コンビネータが要る • パフォーマンスが高い必要がある • 参照透明でありながら高いパフォーマンス...
- 71. 抽象力が要る • 抽象力とはプログラマーの力の源泉 • 抽象化の敵、IO
- 72. IOと抽象化 • IOがある関数は抽象化出来ない • 外界とのやり取りは常に直接的 • 部分的な捨象が出来ない • 抽象度に応じた扱いが出来ない ➡IOは切り取る／隔離するしかない
- 73. 参照透明な世界へ • 参照透明な言語はIOを明示的に扱う • 型を調べれば副作用の有無が分かる ➡参照透明な世界が見える！ 参照透明な海を守る会 http://www.paraiso-lang.org/ikmsm/
- 74. コンビネータが要る • バグなく • 疎結合！ • 参照透過性！ • 組み合わせる • モナド！ • 高階関数！ もう何度も同じ事繰り返してる感が...
- 75. 高いパフォーマンス • 先人の蓄積 • STモナド • 参照透明で安全な破壊的代入 • Vector • Deforestation/recycling • BlazeBuilder • 差分リスト • Repa • IntMap
- 79. Haskellのテスト • コンパイルが通れば型のエラーはない 1. 型でなんとかする 2. 値のテストを行う 1. 純粋関数 2. 非純粋関数
- 80. 型でなんとかする • j :: Int -> TypeD • Int指定しているが、実際にはその部分集合で十分 • 型は値の集合 • 使わない値はバグの元 • data OneToThree = One | Two | Three • Intで使わない部分を排除する ➡ コンパイルがテストになる！
- 81. 型でなんとかする • デメリット • コストが高い • 適用範囲が少ない • 1000個の場合はどうするの？ • えーとTemplate Haskellで... • あまり実用的ではないか... • 依存型、軽い構文が望まれるか...
- 82. 値のテスト • 純粋関数 • 参照情報は引数のみ • 外部への影響は一切無い ➡ 引数に対する返り値のみチェックすればいい 外部への影響は 一切無い！ 参照情報は 引数のみ TypeA f TypeB
- 83. 値のテスト • 純粋関数 • QuickCheck • 型からテストケースを自動生成する • 参照透過性を持つ言語で力を最大限発揮 • SmallCheck • 値の範囲を制限して総当たりテスト（確か）
- 84. 値のテスト • 副作用ありの関数 • HUnit • HSpec • 事前条件、事後条件チェック
- 85. リファクタリング • テストが簡単 • リファクタリングが簡単！ • 関数同士の依存が極めて少ない • 大規模なリファクタリングにはならない（多分
- 86. 仕様変更 • 変更に伴う箇所をコンパイラが教えてくれる！ • コンパイラに教えてもらえる様に型を作ろう
Editor's Notes
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n