Haskell Day2012 - 参照透過性とは何だったのか
•Als KEY, PDF herunterladen•
52 gefällt mir•15,030 views
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Mehr von Kousuke Ruichi
Kürzlich hochgeladen
Kürzlich hochgeladen (9)
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. 仕様変更 • 変更に伴う箇所をコンパイラが教えてくれる！ • コンパイラに教えてもらえる様に型を作ろう
Hinweis der Redaktion
- \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