Introduction to Functional Programming

Introduction to
Functional Programming
Copyright © PIXELA CORPORATION. All Rights Reserved.｜PIXELA CORPORATION PROPRIETARY AND CONFIDENTIAL.
株式会社ピクセラ
先端技術開発部
2019年08月19日

関数とコンテナ型クラス
2

Function
Type A => Type B へのマッピング
3

map (メソッドの方)
Functionはマッピングなのに mapメソッド?
4

List::map
List[1, 2, 3].map(i => i + 1) => List[2, 3, 4]
5

ダイアグラム
6
A BNormal
f

ダイアグラム
7
A B
List[A] List[B]
Normal
Lifted
f
List::map コンテナ層に適用可能にする

List
List[A] = Head of List :: Tail of List
Tail of List = (Head of (Tail of List)) :: (Tail of (Tail of List))
Tail of Tail of List = …
Tail of Tail of … = Nil
-> Head::TofHead::TTofHead::…Nil
8

List (scala的)
sealed trait List[+A]
case object Nil extends List[Nothing]
case class Cons[+A](head: A, tail: List[A]) extends List[A]
9

fold[Right|Left]
def foldRight[A, B](as: List[A], z:B)(f: (A, B) => B) : B = as match {
case Nil => z
case Cons(x, xs) => f(x, foldRight(xs, z)(f))
}
@annotation.tailrec
def foldLeft[A, B](as: List[A], z:B)(f: (B, A) => B) : B = as match {
case Nil => z
case Cons(x, xs) => foldLeft(xs, f(z, x))(f)
}
関数fが多数回呼ばれる => fに副作用を入れないことがいかに重要か
10

Folds are primitive functions for List class
def List::map[A, B](la:List[A])(f: A -> B) : List[B]=
foldRight(Nil[List[B]])((h, t) => f(h) :: t))
11

ダイアグラム
12
A B
List[A] List[B]
Normal
Lifted
入力
f
入力がList[A]の場合、
f にある操作をして
出力をList[List[B]]ではなく、
List[B] にするには？
List要素 1つ1つで
List[B]ができるf

ダイアグラム
13
A B
List[A] List[B]
Normal
Lifted
入力
f
f’
f’ を作るには？

List::flatMap (scala)
def append[A](la: List[A], lb: List[A]): List[A] = la match {
case Nil => lb
case Cons(h, t) => Cons(h, append(t, lb))
}
def List::flatMap[A, B] (ls: List[A])(f: A => List[B]): List[B] =
foldRight(ls, Nil:List[B])((h, t) => append(f(h), t))
14

ダイアグラム
15
A B
List[A] List[B]
Normal
Lifted
入力
f
f’
List::flatMap

命令型記述と関数型記述
16

Imperative Programming Style
TypeA a = funAFromUnit();
TypeB b = funAToB(a);
TypeC c = …
17

表現方法の変換
chain(x:input, f: x => y) = f(input)
chain(funAFromUnit(), a =>
chain(funAToB(a), b =>
chain(fun…)))
18

Functional Programming Style
chain(funAFromUnit(), a =>
chain(funAToB(a), b =>
chain(fun…)))
funAFromUnit() を入力とし、後続全てを丸ごとFunctionであると
捉えられる。後続中も同様の構造となる。 == 再帰的
Imperative的表現を Functional 的表現で再現した。
19

Functionalの有利な点
chain が function
=>function中で操作が可能。
20

この有利な部分を有効に使いたい。
21

例日常のコード
def proc_nest(a:A): C = {
val b = funAtoB(a)
if (isValid(b) == true) {
val c = funBtoC(b)
if (isValid(c) == true) c else Nothing
}
Nothing
}

例日常のコード
23
def proc_flat(a: A) : C = {
val b = funAtoB(a)
if (isValid(b) != true) {
Nothing
}
val c = funBtoC(b)
if (isValid(c) != true) {
Nothing
}
c
}

問題点
関数が本来やりたい記述が埋もれる
24

別の大問題＝＞ Exception の存在
25

Function的問題点
○ 関数IF中にExceptionの情報は無い。
proc: A=>C
Exceptionは副作用
26

ターゲット
関数本来の処理記述が埋もれさせず
かつ
(見た目上)例外を発生させない
表現にしたい
27

Railway Programming
28
元ネタ https://fsharpforfunandprofit.com/posts/recipe-part2/
Left(e)
Right(b;B)a:A
f
sealed trait Either[+E, +A]{
…
}
case class Left[+E](value: E) extends Either[E, Nothing]
case class Right[+A](value:A) extends Either[Nothing, A]
Optionalの親戚的

Railway function
29
def railway[A, B, E](f: A => B): A => Either[E, B] = a => {
try {
if (a == Nothing) {
Right(Nothing)
}
val result = f(a)
if (isValid(result) == true) Right(result)
else Right(Nothing)
} catch(exception e) {
Left(e)
}
}

それぞれを
30
Left(e)
Right(c)b
railway(funBtoC)
Left(e)
Right(b)a
railway(funAtoB)

連結できたら良くない？
31
Left(e)
Right(c)b
Left(e)
Right(b)a
しかし
railway(funAtoB) と railway(funBtoC)の入出力の型式が違う
railway(funAtoB) railway(funBtoC)

ダイアグラム
32
A B
Either[E, B]
Normal
Lifted
funAtoB
railway(funAtoB)
C
Either[E, C]
railway(funBtoC)
funBtoC

ダイアグラム
33
A B
Either[E, B]
Normal
Lifted
funAtoB
railway(funAtoB)
C
Either[E, C]
railway(funBtoC)
funBtoC
Either::flatMap

flatMap 実装
sealed trait Either[+E, +A]{
def flatMap[EE >: E, B](f : A => Either[EE, B]):
Either[EE, B] = this match {
case Left(e) => Left(e) // * point
case Right(a) => f(a)
}
34

35
Left(e)
Right(c)Right(b)
Left(e)
Right(b)a
railway(funAtoB) Either::flatMap(railway(funBtoC))
Left(e)

Left(e)
Right(c)
railway(funAtoB) railway(funBtoC)Either::flatMap
a

railway(funAtoB) railway(funBtoC)Either::flatMap
一旦 Leftに分岐すると、何も処理されずスルーされる。
Left(e)
Right(c)a
*point

例日常のコード改
38
def proc_rail[A, C, E](a: A) : Either[E, C] = {
Right(a).flatMap(a =>
railway(funAtoB)(a).flatMap(b =>
railway(funBtoC)(b)))
}

演算子擬似コード
39
def (>>=)[A,B,E](eith:Either[E, A])(f:A => Either[E,
B]):Either[E, B] = {
eith.flatMap(a => f(a))
}

40
def proc_rail[A, C, E](a: A) : Either[E, C] = {
Right(a)
>>= railway(funAtoB)
>>= railway(funBtoC)
}
演算子>>= を使った擬似コード

ダイアグラム
41
A B
Either[E, B]
Normal
Lifted
railway(funAtoB)
C
Either[E, C]
railway(funBtoC)
Either[A, E]

結合則条件
42
Right(a).flatMap(f).flatMap(g) ==
Right(a).flatMap(aa => f(aa).flatMap(g))
→ flatMapの並列結合したものと、ネストしたflatMapが同値
これと、単位元の存在条件を満たすコンテナクラスの持つ特徴

Monad!
Monadは、計算の継続を抽象化したもの。
わかりやすい単語表現 “Chainable”
flatMap は別名 bind と言われることもある。
43

Either::map
def Either::map[A, B](ea:Either[E, A])(f: A => B): Either[E, B]
= ea.flatMap(a => Right(f(a)))
44

さらなる応用
List::map(la:List[A], f:A => Either[E, A]): List[Either[E, A]]
List[Right[A], Left[E], Right[A], …] となる場合を考える。
この時、 Listの中にLeftが出てくることを許容できないケースがある
とする。
45

List[Either[E, A]] が、 Either[E, List[A]] となるようにしたい。
46

map2
def Either::map2[E, A, B, C](ea: Either[E, A], eb: Either[E, B],
f: (A, B) =>C) : Either[E, C] =
ea.flatMap(a =>
eb.map(b =>
f(a, b)
))
47

ちょっと脱線 zip
Either::zip[E, A, B](ea: Either[A], eb: Either[E, B]) : Either[E,
(A, B)] =
Either::map2(ea, eb) ((a, b) => (a, b))
48

sequence
49
def sequence[E, A](es: List[Either[E, A]]): Either[E, List[A]] =
es.foldRight[Either[E,List[A]]](Right(Nil))((head_e, tail_e) =>
Either::map2(head_e)(tail_e)((head, tail) => head::tail))

ダイアグラム sequence
50
A ANormal
Either[A, E]
List[Either[A, E]] Either[List[A], E]
List[A, E]

まとめ
○ mapのような高階関数はListだけでなく、様々なコンテナ型クラスに実装可能
○ 同じような計算表現の高階関数を定義できる。
○ 命令型記述を関数型記述で実現可能となるだけでなく、行間に追加機能を持たせられる。
最上位の表現においては追加機能の詳細記述が隠蔽される。
○ コンテナ型クラスを多層に出来、さらに層の入れ替えを実現する演算がある。
51

追加情報
○ 普段使うコンテナ型クラスはmonad性質がある。
→ 普段のプログラムは、全てmonad性質を持つコンテナ型クラスで構成できる。
○ List, Stream (遅延評価)
○ Optional(==Nullable), Either
○ State
○ Async, Parallel
(︎↑を基本とし、さらに上位のライブラリを作れる。
例. テストライブラリ(テストデータ自動生成 & データに対する性質テスト)
パーサーライブラリ(500行程度でパーサーライブラリ&Jsonパーサ合わせたものがかけます)
○ Reader-monad, Writer-Monad, IO-Monad 等もある
○ Monad(継続 == 命令型的記述)に関連して、関数型言語では、特別な記述様式が用意されている
Haskell : do記法, Scala: for記法, F#: computation記法
52

追加情報
○ unit, flatMap をprimitiveとして、上位Combinatorを実装可能なものが多い。
○ map, mapN, zip, sequnence, transverse…
○ unit, map2 をprimitiveにすることも可能 primitiveの選択性)
○ コンテナ型クラスのメソッドがある規則を満たせば、それらクラスがさらに抽象的なグループに分別できる
例 Functor 属性
map に対する規則 containr::map[A](c:container, f: A => A) について、
container::map(c, (a => a)) == a
が成立するもの
○ 演算に対しても同様にグループ分けもできる。
例 Monoid 属性
結合則 op(op(x, y), z) == op(x, op(y, z)) と単位元の存在
実例 String , List の加算
=> foldable との関係性につながる
53

所感
メリット:
○ FPはプログラムを統一型式で表現可能な手段を与えてくれる。
→ “統一“というプログラマがコーディング重要指標にあげる点を、徹底的に実現可能。
→ 言語を超えた統一表現
○ FPがもつ真のmodular性
デメリット:
学習コストの高さ
FP以外にも、FPと同様の統一型式表現手段があればそれを選択すれば良いですが、恐らくそれも学習コストの高さがあると思います。
 結局 2択
皆さんが普段戦っている、プログラムを組む時の大問題”複雑性”に対して
* いわゆる普通の命令型の表現を選択して、一つ一つの処理は簡単だが、結果複雑で大きくなり易いコードを書いていく
or
* 高い学習コストを払ってでも新しい表現を選択し、複雑性を隠蔽できるコードを書いていくか
54

参考書 & 参考サイト
https://www.manning.com/books/functional-programming-in-scala
https://fsharpforfunandprofit.com

Introduction to Functional Programming

Introduction to Functional Programming

Recommandé

Recommandé

Contenu connexe

Plus de PIXELAcorporation

Plus de PIXELAcorporation (7)

Introduction to Functional Programming