もくもくiOS勉強会@ネクスト 1周年記念LT会

1. Swiftでの関数型プログラミングについて
考えていること
@akio0911

2. 参考になる書籍
http://www.amazon.co.jp/dp/4274068854

3. 参考になる書籍
http://www.amazon.co.jp/dp/B00UY3K04O

4. Multi-paradigm
Swift is a multi-paradigm, compiled programming
language created by Apple Inc. for iOS, OS X, and
watchOS development.
https://en.wikipedia.org/wiki/Swift_(programming_language)

5. Multi-paradigm
• Object-oriented programming
• Protocol-oriented programming
• Functional programming

6. 関数型プログラミングの特徴
• コード量が少なくなる
• 最適化がしやすい
• 並行/並列化がしやすい
• バグり/バグらせにくい
• ドキュメントが少なくなる
引用元 : 関数プログラミング実践入門 4ページ

7. 純粋関数型プログラミング言語
Haskell
• 「何をするか」ではなく「何であるか」を伝える
• 一度変数の値を設定すると、後でそれを別の値に変更することはできない
• 関数は副作用を持たない（参照透明性）
• 遅延評価
• 静的型付け言語
• 型推論
• エレガントで簡潔

8. 「何をするか」ではなく
「何であるか」を伝える
CPUで行っていることと一対一で対応している

9. 「何をするか」ではなく
「何であるか」を伝える
「合計とは何か？」を書く
合計とは「1個目の数値 + 残りの要素の合計」である
要素数0の配列の合計は0である

10. sum2([1, 2, 3, 4, 5])
1 + sum2([2, 3, 4, 5])
1 + (2 + sum2([3, 4, 5]))
1 + (2 + (3 + sum2([4, 5])))
1 + (2 + (3 + (4 + sum2([5]))))
1 + (2 + (3 + (4 + (5 + sum2([])))))
1 + (2 + (3 + (4 + (5 + 0))))
1 + (2 + (3 + (4 + 5)))
1 + (2 + (3 + 9))
1 + (2 + 12)
1 + 14
15

11. reduce
パックマン的な処理を書くための汎用的な処理

12. 0
1 2 3 4 50 + 1 -> 1
1
2 3 4 51 + 2 -> 3
3
3 4 53 + 3 -> 6
6
4 56 + 4 -> 10
10
510 + 5 -> 15
15
・パックマンの初期値
・パックマンに食わせるコレクション
・パックマンが食った後の新たなacc
を指定できるのがreduce

13. acc num new acc rest
0 1 0 + 1 -> 1 [2, 3, 4, 5]
1 2 1 + 2 -> 3 [3, 4, 5]
3 3 3 + 3 -> 6 [4, 5]
6 4 6 + 4 -> 10 [5]
10 5 10 + 5 -> 15 []

14. reduce
パックマンをイメージすると、分かりやすく見えてくる

15. 一度変数の値を設定すると、
後でそれを別の値に変更することはできない

16. varのデメリット
var a = 10
様々な処理
let result = function(a)
functionに何が渡されるかは
ここをすべて読まないと断定できない

17. letのメリット
let a = 10
様々な処理
let result = function(a)
ここだけ読めば、
functionに何が渡されるかが断定できる

18. mutating keyword
structではプロパティを書き換える場合はmutatingが必要
（classの場合は不要）
varにしないといけない

19. mutating keyword
• 構造体を「データの入れ物（状態変化を伴う）」
ではなく、「構造を持つ1個のデータ」と考えて
いるっぽい
• classはreference typeで状態を持つ。structは
value typeで状態を持たない、という扱いをす
ると良さそう

20. 状態を変化させず
新たなデータを生成する
Swiftではletを使え！というメッセージを
ここからも感じる
letでOK！
Swiftではletを使え！というメッセージをここからも感じる

21. Higher-order function
引用元 : Functional programming in Swift

22. Higher-order function
座標を渡すと、それが領域内に含まれているか否かを
Boolで返してくれる関数型を定義
これが意味深！

23. Higher-order function
関数のインターフェースさえ えれば
部品として組み合わせられる。
クラスの継承などは部品として大げさな場合がある？

24. Higher-order function
関数のインターフェースが っているので
部品としてかなり自由に組み合わせられる

25. Operatorを定義すると便利に書ける
ここらへんが微妙？強制アンラップしないと、
失敗する可能性のある処理を、次の処理につなげられない

26. 失敗する可能性のある処理を
つなげられる演算子
参考 : http://qiita.com/koher/items/
95583f58a443f6a33c28

27. 失敗する可能性のある処理を作る

28. 失敗する可能性のある処理をつなげる
Optional Chain(a?.b?.c)の関数版？
エラーを処理するif文などが不要になった。

29. 失敗する可能性のある処理を2つ合成して
失敗する可能性のある処理を1つ作る演算子

30. 失敗する可能性がある関数を部品としてつなげ合わせて
新しい部品を作れるようになった

31. まとめ
• 「何をするか」ではなく「何であるか」を書く
• reduceは汎用的に使えるパックマン
• 極力letを使って、追いかけやすい（追いかけなく
ても良い）コードを目指そう
• 高階関数を使えば非常に柔軟に書ける（クラスは部
品の実現方法として大げさな場合がある？）
• 失敗する可能性のある処理をそのまま扱えると便利