#w8lt 6回目にやった関数型Swiftとかいう何か

1. 11月のLT FP in Swift
@S_Shimotori

2. たのしい関数型 あかるいSwift
• @S_Shimotori
• 自転車屋さんと予定調整したとき、
「え、平日昼か、休日なら空いてますよ」
って言ったら夜間部と間違われたので、
わたしは夜間部大学生です。

3. 今月のはなし
• 関数型プログラミングは意味がわからない
• そうだSwiftでFPをやろう
• 実際やろうとするとアレ

4. 関数型プログラミングは意味がわからない

5. 春
わたし「SwiftでバイトすればSwiftかけるようになると
思ったらObjCの募集しかないじゃねーか(当然)」
？？？「ウチでやれるよ」
わたし「やったぜ」
雇用主「次の仕事は関数型でSwiftやで」
わたし「おっ洗脳かがんばる∼」

6. 本当に意味がわからない
• カタカナ語を言われてもどれが何でどうなのか不明
• 結局役に立った本
• すごいHな本
• 結局これがわかりやすかった
• これ読むためにHaskell始める価値がある
• FPinScala
• 例外処理の話はとても良かった
• 量が多くサンプルソース的な面でつまみ読みがしづらい
• 私が💢落単💢した👊代数系と符合理論の教科書
• 九九ができないので落単しました＞＜
• モノイドの関係で群だか環だか体だか

7. 結論
• 用語使って理解するのやめよう。

8. ところで: 東工大でのFP教育とは
• 一応SchemeをやってFPをやった気分になる
• 13年に授業受けたわたしの疑問
• なぜScheme(というかFP)をやったのか
• Consと末尾再帰やりたかったんですかね…？
• なぜ最後オブジェクト指向につなげたのか(マジで不明)
• 個人的には結局Arrayを使うのでListはいらない
• 実務上は他のやつを取り上げてくれた方が役立った
• SwiftのListは https://github.com/typelift/Swiftz/ でやれる、一応
• プロ/情実1∼4では一番楽しかった(これは本当)
• インフレに加担しました

9. ちなみに来年
http://www.titech.ac.jp/education/reform/point/pdf/computing/computing_b_02_02.pdf
関数型をついに名乗る

10. そうだSwiftでFPをやろう

11. 題材
• JSONをデコード
• GET等で取った物を取り出しやすくするライブラリは複数ある
• 大抵 json[“key”] って感じでArray使って取る
• FP的手法で取り出そうとするライブラリもある
• Argo( https://github.com/thoughtbot/Argo )
• 派生：Himotoki( https://github.com/ikesyo/Himotoki )
• 紙の上でFP勉強するより実際に役に立ってる所を見ながら
勉強するほうが楽だった
• ので、未だに用語はわからず

12. 使い方
• Model書きます
• decode()を実装します
• protocol Decodableに含まれている
• GETかなにかでもらったものをdecode()に渡します
• Decoded<T>が帰ってきます
• Decoded.valueで目的の値Tを取り出して煮て焼きます

13. 書きました

14. Argoのいいとこ
• デコードしてPersonを作るには複数の段階を踏む
• そこにFPを取り入れるとすっきりする
• 処理がだいたい関数一言とか演算子一言で表せる
• 個人的には手続き型で書くよりわかりやすいと思った
• SwiftyJSON版(https://github.com/SwiftyJSON/SwiftyJSON)
• 動作確認はとってません、多分こんな感じ
• Optionalで処理するのであまり詳細なエラー情報は得られない

15. もっとくわしく
• デコードの結果はenum Decoded<T>で表す
• 「成功(生成物を含む)」
• 「失敗(指定されたキーがjsonにない)」
• 「失敗(指定されたキーはあったが型が違う)」
• 「失敗(その他・カスタム)」
• FP的にtry-catchはダメってFP in Scalaが言ってた
• Exception()はコンテキストに依存する
• 外側のtry-catchを見ないと意味がわからない
• ？？？「なんでSwiftにdo-try導入したんだ……」

16. もっとくわしく
• Decoded<T>(あるいはOptional<T>)は、TをDecoded
で持つことで成功や失敗の意味を含ませることができ
る
• あくまで型としてはDecodedなので、Person.initに
Decoded<String>を渡すことはできない
• Decoded<String>から取り出して代入する動作が必
要

17. というわけで
• 入力(?)
• Person.init
• json <| “name”で得られたDecoded<String>
• json <| “age”で得られたDecoded<Int>
• <| は最終的にはo[key]って感じで取り出してる
• 出力
• Decoded<Person>

18. みんな大好きcurry
• 今回のPersonはnameとageを要する
• イニシャライザそのままでは一度に両方与える必要が
ある
• curry化すると順番にnameとageを与えられるように
なるので、今回のような場合には有用
• nameデコード→代入→ageデコード→代入
→Personの完成
• curry==部分適用って言うと逮捕されるって聞いた

19. あとはひたすら出して代入して入れる

20. FunctorとApplicative
• 作業途中の関数とjsonから取り出した要素は全てDecodedの
中に入っている
• 1つ目は関数は生身で、nameはDecodedに入っているのでそ
ちらだけ取り出す動作が発生
• Functorって言うらしい。
• <$>って書けないから<^>で代用してるらしい
• 2つ目以降は関数も引数もDecodedに入っているので両方取
り出さないといけない
• Applicativeって言うらしい。

21. とはいうものの、実際やろうとするとアレ

22. Swiftクオリティ
• 圧倒的演算子の無さ
• Haskell他が標準で持っている演算子を持っていない
• <$><*>とか、関数合成とかもない
• ちょっと前までflatMapもなかった
• mapはあったくせに
• Argoの中身は演算子定義と型定義って感じ。
• 型推論がよわい
• Argoやってると割と推論に失敗する

23. Argoは推論に頼りっきり
Decoded<String>
Decoded<Int>
Decoded<Optional<String>>
Decoded<Int>
(Optional<String>>) -> String
String -> Int -> Person
そして戻り値Decoded<Person>なので全体的にもOK

24. Swiftの型推論の限界
• <^>と<*>だけやってる間はきっと平気
• ↑と一緒にmapとflatMapを使いすぎるとエラーが出る
• >>-って書くとエラーで、flatMapって書くとOKだっ
たりする
• ↓のようなエラーは要するに型推論が辛いという意味だ
が、どこで推論失敗しているのかはわからない
• エラー消えるまで分割を試行していくしかない

25. 途上なので
• あと、継承しようとすると爆発します
• 「Class variables not yet supported」の再来

26. 結論

27. 結論
• 型推論なんとかしろー
• a >>- f って無理に書かずにa.flatMap{f}って書こう
• protocolから来たメソッドの継承なんとかしろー
• Argoはいい教材だ
• 初期値や定義域チェックをいかにすっきり書くかは
なかなかたいへん。。
• switch/map/flatMapはおともだち