Your SlideShare is downloading. ×
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Haskell Day2012 - 参照透過性とは何だったのか
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

12,395

Published on

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

No Downloads
Views
Total Views
12,395
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
82
Comments
0
Likes
39
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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
  • Transcript

    • 1. 参照透過性とは何だったのか version 0.0.1 ruicc
    • 2. はじめに• つっこみ所が満載のスライドです。 • お手柔らかにお願いします。• 長いです。 • 巻きます。
    • 3. 自己紹介• @ruicc• Ruichi Kousuke• 好きな作曲家:A. Bruckner• 好きなバイオリニスト:Hilary Hahn• 好きな言語:Haskell• 爆発すればいい言語:PHP
    • 4. はじめに• にあふれる • 「Haskellこわい」 • 「関数型こわい」 • 「なごやこわい」 (いやこれは関係ないけど..
    • 5. Haskellとは• 先人の知識と知恵の蓄積の上に成り立つ• コンピュータサイエンスの結晶
    • 6. 昔の偉い人は言いました巨人の肩の上に立つ Bernard of Chartres
    • 7. 「Haskell == 巨人」説
    • 8. Haskellどう見える• 使った事無い人 • 巨人を見上げる ➡こわい• 使った事ある人 • 巨人の肩の上に立つ ➡頼もしい
    • 9. ぴったりだ!
    • 10. 巨人の肩の上に立とう!
    • 11. このスライドの範囲• 強い型付• 静的型付• 参照透過性
    • 12. 強い静的型付け言語Java Haskell Scala C# OCamlC++ F# Clean SML# D
    • 13. オブジェクト指向 オブジェクト指向言語Java Haskell Scala C# OCamlC++ F# Clean SML# D
    • 14. みんな大好き強い静的型付関数型 関数型言語Java Haskell Scala C# OCamlC++ F# Clean SML# D
    • 15. よくある認識 オブジェクト指向言語 関数型言語Java Haskell Scala C# OCamlC++ F# Clean SML# D
    • 16. このスライドの範囲 純粋関数型言語Java Haskell Scala C# OCamlC++ F# Clean SML# D
    • 17. 交わらない何か オブジェクト指向言語 純粋関数型言語Java Haskell Scala C# OCamlC++ F# Clean SML# D
    • 18. Note: OOPLと純粋性• オブジェクト指向言語に純粋性は相容れない? • メソッドはメンバの参照が必要 • メソッドを純粋には出来ない • オブジェクト単位で見たら純粋性?は確保出来る • コンストラクタ以外の情報を用いない??
    • 19. 純粋関数型言語とは• Purely Functional Programming Language • (他パラダイムが混じらない純粋な 関数型) の言語 ←まちがい! • (純粋 && 実用的)な言語 ←せいかい! • 参照透過性を持った言語
    • 20. 参照透過性?• Referencial Transparency • 式や言語の性質(以降言語の性質として用いる) • 返り値が引数のみによって決まる性質 • 引数が同じなら返り値は常に同じ
    • 21. つまり?• 非常に厳しい制約に見える • (実際厳しい)
    • 22. 参考:念能力• 強い制約 → 強い力 • This way.
    • 23. 参照透過性のとある説明• どんな時でも返り値が引数によってのみ決定する• よってメモ化しやすい
    • 24. えっ...
    • 25. 参照透過性のとある説明2• どんな時でも返り値が引数によってのみ決定する• マルチコアプログラミングが容易
    • 26. いやいやいや
    • 27. そうじゃないだろ
    • 28. 知りたい事•参照透過性で俺たちはどんな力を得るのか•俺たちの現実はどう変わるのか
    • 29. 目次• 型と参照透過性• 設計と参照透過性• 抽象化と参照透過性• テストと参照透過性
    • 30. 型と参照透過性  ——Haskellの型の上に立つ
    • 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. Haskellのテスト• @kazu_yamamotoさんが色々言及しましたし• 省略していいですか。
    • 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. まとめ•参照透過性を持つ言語ならHaskellがオススメ!
    • 90. まとめ•Haskellやろうぜ!
    • 91. Enjoy YourHappyHackingHaskell!!

    ×