Haskell Day2012 - 参照透過性とは何だったのか

15,301 views
14,956 views

Published on

Published in: Technology
0 Comments
50 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
15,301
On SlideShare
0
From Embeds
0
Number of Embeds
583
Actions
Shares
0
Downloads
94
Comments
0
Likes
50
Embeds 0
No embeds

No notes for slide
  • \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
  • Haskell Day2012 - 参照透過性とは何だったのか

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

    ×