第二回関西関数型勉強会の発表資料です。

1. Better C#の脱却を目指して
bleis-tift
November 24 2012

2. 自己紹介
id:bleis-tift / @bleis
なごや (こわくない)
Microsoft MVP for Visual F#
仕事は F#もやるけど、C#も

3. 対象
関数型言語初心者を抜け出しつつある人

4. それなりによく見る光景
今まで手続型の言語を使っていたチームで・ ・・
C#の代わりに F#を使おう！
(もしくは、Java の代わりに Scala を使おう！)
→ C#や Java のコードを単に置き換えただけ

5. Better ○○
便利になる部分はある。
が、便利な○○どまり、と言うことも多いように
思う。
「便利な○○」を抜け出すためには壁がある
と、思う

6. 壁の例
再帰関数の壁
高階関数の壁
カリー化、コンビネータ、関数合成の壁
型を定義する壁
各言語ごとのよりディープな壁
パラダイムの壁を越えるのは大変・
・・

7. 型を定義する壁
C#や Java をはじめとする手続型言語では、
型の定義が面倒
型をあまり定義しない習慣
プリミティブな型で済ませてしまう
この悪習を、F#などにも持ち込んでしまう
結果、if-elif-else の嵐になるなど

8. C#での型定義
User クラス
public class User
{
public readonly string Name;
public readonly int Age;
public User(string name, int age)
{
this.Name = name;
this.Age = age;
}
public override bool Equals(object obj)
{
var other = obj as User;
if (other == null)
return false;
return this.Name == other.Name && this.Age == other.Age;
}
public override bool GetHashCode()
{
return this.Name.GetHashCode() ^ this.Age.GetHashCode();
}
public override string ToString()
{
return string.Format("User(Name={0}, Age={1})", Name, Age);
}
}
面倒！

9. F#での型定義
User レコード
type User = {
Name: string
Age: int
}
簡単！

10. 比べてみる
C#では、ごてごてした修飾子が必要
C#では、コンストラクタでフィールドの初
期化が必要
C#では、Equals や ToString 等のオーバーラ
イドが必要
==や!=などを使うと思ったら更に以下略
大小比較しようと思ったら更に更に以下略
F#は全部不要。簡単な値クラス程度のものなら
レコードを使えば十分。

11. タプルとの使い分けは・ ？
・・
タプル
("山田 太郎", 20)
関数内に閉じていればタプルでいい
外部に公開するような関数の in/out はレ
コード
フィールドがたくさんある場合はレコード
F#の場合、||| > 演算子で扱えない、4 つ以上の
タプルは極力使わないとか
型を定義してからロジックを書く
型駆動！

12. if-elif-else の嵐
時刻と光の強さと雨の量から、天気を判断し
たい。
雨の量が 0
7 時∼17 時
光の強さが 5 以上なら晴れ
それ以下なら曇り
18 時∼4 時なら晴れ
それ以外
光の強さが 3 以上なら晴れ
それ以外なら曇り
雨の量が 20 以上なら大雨
20 未満なら雨

13. 愚直に実装すると・
・・
let doSomething prec time luminance =
if prec = 0 then
if 7 <= time && time <= 17 then
if luminance >= 5 then
// 晴れ
else
// 曇り
elif time <= 4 || time >= 18 then
// 晴れ
else
if luminance >= 3 then
// 晴れ
else
// 曇り
elif prec >= 20 then
// 大雨
else
// 雨

14. このコードの欠点
似たような関数がいたるところに量産される

15. アクティブパターンに押し込める
let (|Sunny|Cloudy|Rain|HeavyRain|)
(prec, time, luminance) =
if prec = 0 then
if 7 <= time && time <= 17 then
if luminance >= 5 then Sunny
else Cloudy
elif time <= 4 || time >= 18 then Sunny
else
if luminance >= 3 then Sunny
else Cloudy
elif prec >= 20 then HeavyRain
else Rain
let doSomething prec time luminance =
match prec, time, luminance with
| Sunny -> // 晴れ
| Cloudy -> // 曇り
| Rain -> // 雨
| HeavyRain -> // 大雨

16. アクティブパターンの利点・欠点
ロジックをアクティブパターンに分離できた
doSomething の見通しが非常によくなった
パターンマッチによる網羅性のチェ ック
欠点としては、prec と time と luminance の順番を
間違う可能性がある

17. 型を導入する
type Weather =
Sunny | Cloudy | Rain | HeavyRain
with
static member Create prec time luminance =
if prec = 0 then
if 7 <= time && time <= 17 then
if luminance >= 5 then Sunny
else Cloudy
elif time <= 4 || time >= 18 then Sunny
else
if luminance >= 3 then Sunny
else Cloudy
elif prec >= 20 then HeavyRain
else Rain
let doSomething weather =
match weather with ...

18. 型を導入した利点
アクティブパターンと同じ利点に加え、
順番を間違える可能性のある場所を、生成部
分に絞れる
組み合わせの数を掛け算から足し算に

19. match 式を活用する方向に進める
if-elif-else を書き始めたら危険信号
when によるガード条件も同様
match 式を使うために型をどんどん定義する
その型を使う側でウマー

20. まとめ
Better ○○を抜け出すには壁がある
型を定義する壁を越えるために・ ・・
if-elif-else を使わない
when も使わない
他の壁は各自越えていく感じで