Download as KEY, PPTX
Haskell Day2012 - 参照透過性とは何だったのか
- 1.
- 2. はじめに • つっこみ所が満載のスライドです。 •お手柔らかにお願いします。 • 長いです。 • 巻きます。
- 3. 自己紹介 • @ruicc • RuichiKousuke • 好きな作曲家：A. Bruckner • 好きなバイオリニスト：Hilary Hahn • 好きな言語：Haskell • 爆発すればいい言語：PHP
- 4. はじめに • にあふれる •「Haskellこわい」 • 「関数型こわい」 • 「なごやこわい」 （いやこれは関係ないけど..
- 5.
- 6. 昔の偉い人は言いました 巨人の肩の上に立つ Bernard of Chartres
- 7.
- 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 FunctionalProgramming Language • （他パラダイムが混じらない純粋な 関数型） の言語 ←まちがい！ • （純粋 && 実用的）な言語 ←せいかい！ • 参照透過性を持った言語
- 20. 参照透過性？ • Referencial Transparency • 式や言語の性質（以降言語の性質として用いる） • 返り値が引数のみによって決まる性質 • 引数が同じなら返り値は常に同じ
- 21. つまり？ • 非常に厳しい制約に見える •（実際厳しい）
- 22. 参考：念能力 • 強い制約 → 強い力 •This way.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29. 目次 • 型と参照透過性 • 設計と参照透過性 •抽象化と参照透過性 • テストと参照透過性
- 30.
- 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
- 51.
- 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に依存する
- 55.
- 56.
- 57.
- 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. モジュール内の密結合 • かんたん！ •モジュール内部でのみ扱う型をつくる • モナドでコンテクストを特定させる
- 66.
- 67.
- 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
- 76.
- 77.
- 78.
- 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. 仕様変更 • 変更に伴う箇所をコンパイラが教えてくれる！ •コンパイラに教えてもらえる様に型を作ろう
- 87.
- 88.
- 89.
- 90.
- 91.
Editor's Notes
- #2 \n
- #3 \n
- #4 \n
- #5 \n
- #6 \n
- #7 \n
- #8 \n
- #9 \n
- #10 \n
- #11 \n
- #12 \n
- #13 \n
- #14 \n
- #15 \n
- #16 \n
- #17 \n
- #18 \n
- #19 \n
- #20 \n
- #21 \n
- #22 \n
- #23 \n
- #24 \n
- #25 \n
- #26 \n
- #27 \n
- #28 \n
- #29 \n
- #30 \n
- #31 \n
- #32 \n
- #33 \n
- #34 \n
- #35 \n
- #36 \n
- #37 \n
- #38 \n
- #39 \n
- #40 \n
- #41 \n
- #42 \n
- #43 \n
- #44 \n
- #45 \n
- #46 \n
- #47 \n
- #48 \n
- #49 \n
- #50 \n
- #51 \n
- #52 \n
- #53 \n
- #54 \n
- #55 \n
- #56 \n
- #57 \n
- #58 \n
- #59 \n
- #60 \n
- #61 \n
- #62 \n
- #63 \n
- #64 \n
- #65 \n
- #66 \n
- #67 \n
- #68 \n
- #69 \n
- #70 \n
- #71 \n
- #72 \n
- #73 \n
- #74 \n
- #75 \n
- #76 \n
- #77 \n
- #78 \n
- #79 \n
- #80 \n
- #81 \n
- #82 \n
- #83 \n
- #84 \n
- #85 \n
- #86 \n
- #87 \n
- #88 \n
- #89 \n
- #90 \n
- #91 \n
- #92 \n
- #93 \n