オーバーロードって素晴らしいですよね！

C# F#

オーバーロード

いやぁ、オーバーロードって素晴らしいものですよね。 例えばC#でintを取るメソッドと、stringを取る同じ名前のメソッドを書きたくなったとするじゃないですか。 そんな時でも、C#はメソッドのオーバーロードが出来るので、こう書けるわけですよ。

public Hoge Something(int x) { ... }
public Hoge Something(string str) { ... }

素敵ですね！

関数(Funcデリゲート)

では、関数を考えてみましょう。 非ジェネリックなメソッドはreadonlyなフィールドとしても定義できますよね。

public static Func<int, Hoge> Something = ...

このSomethingは、他のメソッドと同じように呼び出せます。 SomethingがHogeクラスに定義されていたとしたら、

var res = Hoge.Something(10);

と出来るわけです。 メソッドの時と変わりませんから、簡単ですね。

ではこれに、stringを受け取ってHogeを返す関数も追加して・・・

public static Func<int, Hoge> Something = ...
public static Func<string, Hoge> Something = ...

出来ない！！！

はい。 フィールドやプロパティはオーバーロード出来ないのですね・・・

ということで、関数をフィールド(やプロパティ)として定義出来るように見えたとしても、 C#ではフィールドやプロパティのオーバーロードが出来ないため、メソッドでできること全部は実現できません*1。

関数を返すメソッド

ここで、関数を返すメソッドを考えてみましょう。 例えば、intを受け取ると「stringを受け取ってHogeを返す関数」を返すようなメソッドです。

public static Func<string, Hoge> Something(int i) { ... }

この関数は、引数を1つ渡すと関数が返ってくるので、そこにさらに引数を渡すことでHoge型の値が返ってきます。

// Hoge.Something(10)で返ってきた関数に"hoge"を渡す
var res = Hoge.Something(10)("hoge");

これ、2つ引数を取るメソッドと似てませんか？

// public static Hoge Something(int i, string str) { ... } があったとして、
var res = Hoge.Something(10, "hoge");

どちらも、引数を2つ渡すことでHogeが得られます*2。

再びオーバーロード

で、ですね。 引数を2つ取るメソッドはオーバーロード出来ます。

public static Hoge Something(int i, string str) { ... }
public static Hoge Something(int i, int j) { ... }

でも、同じようなことが出来る関数を返すメソッドはオーバーロード出来ません。

public static Func<string, Hoge> Something(int i) { ... }
public static Func<int, Hoge> Something(int i) { ... }

C#では、戻り値の型が異なるだけのメソッドがオーバーロード出来ないのです。 ここでも、戻り値の型のオーバーロードが出来ないため、メソッドで出来ること全部を実現することができません。

オーバーロード、確かに便利だけど、関数ではできないのがちょっと残念ですね。 最近だと関数を使う場面というのは多くなっているからなおのこと残念さが増します。

F#はどうか

F#では、関数ではオーバーロードを許していません。

何！？いまどきオーバーロードないだって！？！？そんな言語使えるかー！！！

判別共用体という解決策

メソッドではオーバーロードが使えるんですが、ここでは判別共用体を使いましょう。 判別共用体は、F#でユーザ定義型を提供する方法の一つで、「この中のどれか一つ」を表すことのできる型を定義できます。 これを使うと、something関数に渡せる型を次のように定義できます。

(* 文字列か整数を表す型 *)
type SomethingArgType =
  | Str of string
  | Int of int

非常に簡単に型が作れることが分かります。 この型を使うと、somethingの実装はこう書けます。

let something = function
| Str str -> ...
| Int i -> ...

呼び出し側はこうです。

let res = something (Str "hoge")

オーバーロードするために型を作るの、ちょっとだるい気もしますけど、簡単に型が作れるので割とありな気はします。 他にも、別モジュールに格納するとか、そもそも関数名を分けるという方法も考えられ、まぁ一番適切だと思うものを選択すればいいです。

さて、F#にはオーバーロードがありませんので、関数を返す関数だろうが関係ありません。

(* 上のSomethingArgTypeとかsomethingとは別物 *)
type SomethingArgType =
  | Str of string
  | Int of int
(* 引数を2つ受け取るsomethingを定義 *)
let something i = function
| Str str -> ...
| Int j -> ...

(* 使う *)
let res = something 10 (Str "hoge")
let res = something 10 (Int 20)

あっ・・・オーバーロードいらない・・・

他にも、オーバーロードを削ったおかげで関数の型推論が出来るだとかのメリットもありますが、それはまた別の時にでも。

何が言いたいか

オーバーロードがいらないは完全に言い過ぎですけど、オーバーロードを入れてしまったがために(後から導入した)関数との統一性がなくなってしまっています。 「便利そうだから」という理由だけで言語に機能を盛り込むのではなく、 導入することによるデメリット(将来予定している機能との相性はどうか、とか)も考えたうえで盛り込んでほしいものですよね。 C#が登場した時期に関数型言語の機能を将来取り入れることを見越していたかは正直微妙*3ですが・・・

*1:他にも、ジェネリックメソッドを関数で置き換えることもできません。

*2:関数を返すバージョンは、引数を一度に与える必要がないという違いはあるけど、ここではそこには触れません。

*3:delegateはあるけど、ううむ

そろそろPower Assertについてひとこと言っておくか

Test

タイトルはもちろん釣りで・・・はない！

ちょっと真面目に、Power Assertについて意見を述べたいのです。

そもそもPower Assertって何？

てきとーに説明すると、

普通の比較演算子で普通にassert書けば、失敗時に各部分式の値を表示してくれる

ようなものです。 Groovy製のテスティングフレームワークであるSpockがおそらく本家大本です((要出典。こういう系の発想は割と昔からあったし、Spock以前に実装例がありそうな気がする。そもそも、Spockは最初からPower Assert持ってたのかも調べないといけない。ちなみに、式木を弄ってAssertを組み立てる、というものであれば(PowerAssertよりも情報量は少なくなるものだけど)、自分の知る限りだと2009年6月にこんな記事があります。 http://themechanicalbride.blogspot.jp/2009/06/better-unit-tests-with-testassert-for.html まずはこの時点でのSpockの実装を確認せねば・・・))。

Groovyでこう書くと、

def xs = [0,1,2,3,4]
assert 1 == xs.min()

こうなります。

Exception thrown
10 02, 2013 2:57:46 午後 org.codehaus.groovy.runtime.StackTraceUtils sanitize

WARNING: Sanitizing stacktrace:

Assertion failed: 

assert 1 == xs.min()
         |  |  |
         |  |  0
         |  [0, 1, 2, 3, 4]
         false


    at org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:399)
以下略

おお！値がどうなったか一目瞭然ですね！

Power Assertをユニットテストに使う

どこがどうなったってアサーションに失敗したのかが分かりやすいため、 これをユニットテストのアサーションとして採用する流れがあります。

こんな感じですね。

import groovy.transform.Canonical

@Canonical
class User {
  def name
  def age
}

def a = new User("hoge", 10)
assert a == new User("hoge", 20)

Exception thrown
10 02, 2013 3:05:37 午後 org.codehaus.groovy.runtime.StackTraceUtils sanitize

WARNING: Sanitizing stacktrace:

Assertion failed: 

assert a == new User("hoge", 20)
       | |  |
       | |  User(hoge, 20)
       | false
       User(hoge, 10)
略

Groovy知らなくても、何が起こっているのかはよくわかると思います。

何が起こっているかは、確かに一目瞭然なのですが・・・

俺たちが欲しかった情報はなんだ？

ユニットテストにおいて、最も欲しいのは「どこがどうなっているか」ではなく、 「どこがどう違っているか」じゃないですかね。

「どこがどうなっているか」だけ渡されても、「どこがどう違っているか」は目視で確認しなけりゃならんのです。 だるいのです。 先の例くらいならまだマシですけど、長い文字列とかだと探すの大変です。

import groovy.transform.Canonical

@Canonical
class SomeData {
  String str
  int i
}

Assertion failed: 

assert a == new SomeData("very long long long string", 20)
       | |  |
       | |  SomeData(very long long long string, 20)
       | false
       SomeData(very long long long sting, 19)

19に釣られて、very long long long stringとvery long long long stingの違いを見抜けなくて(本来)無駄なRedになってしまっても、それは仕方がないことですよね。

本当に欲しい情報って、例えばこんなものじゃないですかね？

Assertion failed:

equality check is failed.
difference:
 - SomeData.str: ["...st(-)ing", "...st(r)ing"]
 - SomeData.i: ["(19)", "(20)"]

この下に、どこがどうなったか情報があったら重宝はすると思います。 が、それが最初じゃないでしょう、と言いたいのです。

じゃぁお前が実装しろよ

ここで、「なので実装しました！」とか言えたら超かっちょいいんですけど、 (社内用テスティングフレームワークとして)作りかけて止まっちゃってます・・・
ちょっと別の色々(LangExtとか)に時間が取られちゃってまして・・・

でも、自分が欲しいのは正直こういう形の情報なんですよね。 PowerAssert的な情報は、あると便利だけどそれだけあっても辛いのです。

なので、このエントリの意見に同意してくれて、時間ある人は是非作ってみてほしいんですよね。 Power Assertに「欲しかったのはお前じゃないんだ！」を突き付けたい！！！

ダブル・ディスパッチ～典型的な関数プログラミング・イディオム～

F#

元ネタはダブル・ディスパッチ～典型的なオブジェクト指向プログラミング・イディオム～ です。 これをF#でやってみるとどうなるかやってみましょう。

レンタルショップの例(レベル1)

商品としてCDやDVDを取り扱うレンタルショップを想像・・・するのは面倒でしょうから、コードで示しますね。

type MemberKind =
  | Common
  | Gold

type Member = {
  Kind: MemberKind
}

type ItemKind =
  | CD
  | DVD

type Item = {
  Kind: ItemKind
}

module RentalShop =
  let calculateRentalFee (item: Item) (member_: Member) =
    (* 金額を計算する *)

レンタル料の計算が、商品種別と会員種別の組み合わせによって変わるようです。 一般会員(Common)の場合はどちらのそのままの値段で、ゴールド会員(Gold)の場合はCDが50円引き、DVDが100円引きとかになるんでしょうか。

RentalShop.calculateRentalFeeを何のひねりもなしに実装すると、こうなります(後で明らかにしますが、もっと別の方法があります)。

let calculateRentalFee (item: Item) (member_: Member) =
  match item.Kind with
  | CD ->
      match member_.Kind with
      | Common -> (* 一般会員がCDを借りる場合の料金計算 *)
      | Gold -> (* ゴールド会員がCDを借りる場合の料金計算 *)
  | DVD ->
      match member_.Kind with
      | Common -> (* 一般会員がDVDを借りる場合の料金計算 *)
      | Gold -> (* ゴールド会員がDVDを借りる場合の料金計算 *)

matchが入れ子になっていてなんだか「イヤな感じ」がしますね。

レンタル・ショップの例(レベル2)

レンタル・ショップのモデルを少し修正しましょう。 Itemが価格を持っていないわけがないので、Priceを追加します。 ついでに、レンタル料金の計算は商品オブジェクトにやってもらうようにします。

type MemberKind =
  | Common
  | Gold

type Member = {
  Kind: MemberKind
  (* 多分こいつも名前とか色々持ってる *)
}

type ItemKind =
  | CD
  | DVD

module CD =
  let calcRentalFee price = function
  | Common -> (* 一般会員がCDを借りる場合の料金計算 *)
  | Gold -> (* ゴールド会員がCDを借りる場合の料金計算 *)

module DVD =
  let calcRentalFee price = function
  | Common -> (* 一般会員がDVDを借りる場合の料金計算 *)
  | Gold -> (* ゴールド会員がDVDを借りる場合の料金計算 *)

type Item = {
  Kind: ItemKind
  Price: int
}
with
  member this.CalculateRentalFee(member_: Member) =
    match this.Kind with
    | CD -> CD.calcRentalFee this.Price member_.Kind
    | DVD -> DVD.calcRentalFee this.Price member_.Kind

module RentalShop =
  let calculateRentalFee (item: Item) (member_: Member) =
    item.CalculateRentalFee(member_)

関数を分けたので、matchのネストがひとつ減りました。 これが「よい感じ」かどうかは置いておきましょう。 さぁさらに複雑にしていきますよ！

レンタル・ショップの例(レベル3)

モデルにさらに手を加え、MemberとItemを相互依存させちゃいましょう！

type MemberKind =
  | Common
  | Gold

type ItemKind =
  | CD
  | DVD

type Member = {
  Kind: MemberKind
}
with
  member this.CalculateRentalFeeForCD(item: Item) =
    match this.Kind with
    | Common -> (* 一般会員がCDを借りる場合の料金計算 *)
    | Gold -> (* ゴールド会員がCDを借りる場合の料金計算 *)
  member this.CalculateRentalFeeForDVD(item: Item) =
    match this.Kind with
    | Common -> (* 一般会員がDVDを借りる場合の料金計算 *)
    | Gold -> (* ゴールド会員がDVDを借りる場合の料金計算 *)

and Item = {
  Kind: ItemKind
  Price: int
}
with
  member this.CalculateRentalFee(member_: Member) =
    match this.Kind with
    | CD -> member_.CalculateRentalFeeForCD(this)
    | DVD -> member_.CalculateRentalFeeForDVD(this)

module RentalShop =
  let calculateRentalFee (item: Item) (member_: Member) =
    item.CalculateRentalFee(member_)

実際の計算ロジックはすべてMember内に集約されました！ これで、会員の種類が増えたとしても手を入れる必要があるのはMemberのみで、Itemなどに手を入れる必要はありません。

しかし、RentalShop.calculateRentalFeeやItem.CalculateRentalFeeは処理を受けて流すだけの内容になってしまい、 これらはノイズとまでは言いませんが、処理を追うのが面倒になりました。

また、扱う商品の種類が増えた場合はItemとMember両方に手を入れなければならないので面倒です。

さらに、例えば新しい軸(曜日によって割引率が変わる、とか)が増えた場合も、どうすればいいんでしょうかこれ。

レンタル・ショップの例(レベル4)

いっそ、モデルの定義とロジックを分割してみましょう。

type MemberKind =
  | Common
  | Gold

type Member = {
  Kind: MemberKind
}

type ItemKind =
  | CD
  | DVD

type Item = {
  Kind: ItemKind
  Price: int
}

module RentalShop =
  let calculateRentalFee (item: Item) (member_: Member) =
    match item.Kind, member_.Kind with
    | CD, Common -> (* 一般会員がCDを借りる場合の料金計算 *)
    | CD, Gold -> (* ゴールド会員がCDを借りる場合の料金計算 *)
    | DVD, Common -> (* 一般会員がDVDを借りる場合の料金計算 *)
    | DVD, Gold -> (* ゴールド会員がDVDを借りる場合の料金計算 *)

実はこれ、最初のバージョンのmatchのネストを、タプルのパターンマッチに書き換えただけです。 これでよかったんやー。

共通処理の括りだし

常識的に考えて、一般会員に特別な値引きがあるとは思えません。 おそらく、一般会員は商品のレンタル料金そのままの値段でのレンタルになるでしょう。 レベル3のコードだと、その場合の処理の共通化をしようと思うと、関数に括りだすしかありません。

member private this.CalculateCommonMemberFee(item: Item) = item.Price
member this.CalculateRentalFeeForCD(item: Item) =
  match this.Kind with
  | Common -> this.CalculateCommonMemberFee(item)
  | Gold -> (* ゴールド会員がCDを借りる場合の料金計算 *)
member this.CalculateRentalFeeForDVD(item: Item) =
  match this.Kind with
  | Common -> this.CalculateCommonMemberFee(item)
  | Gold -> (* ゴールド会員がDVDを借りる場合の料金計算 *)

あまり見通しは良くないですね。 それに対して、レベル4のコードだと

let calculateRentalFee (item: Item) (member_: Member) =
  match item.Kind, member_.Kind with
  | _, Common -> item.Price (* 一般会員はそのままの値段 *)
  | CD, Gold -> (* ゴールド会員がCDを借りる場合の料金計算 *)
  | DVD, Gold -> (* ゴールド会員がDVDを借りる場合の料金計算 *)

と、見通しの良い記述が可能です。

曜日によって割引率が変わりました

という場合でも、レベル4のコードであればRentalShop.calculateRentalFeeに引数を増やすだけで対応可能です。

let calculateRentalFee (item: Item) (member_: Member) (dayOfWeek: DayOfWeek) =
  match item.Kind, member_.Kind, dayOfWeek with
  | CD, Common, Tuesday
  | CD, Gold, _ -> (* 火曜日は一般会員もCDがゴールド会員と同じ割引ですって *)
  | DVD, Common, Tuesday
  | DVD, Gold, _ -> (* 火曜日は一般会員もDVDがゴールド会員と同じ割引ですって *)
  | _, Common, _ -> item.Price

まぁ複雑になりすぎる場合は、コンビネータを合成する方向性の方がいいと思いますが、 オブジェクト指向プログラミングでのダブルディスパッチよりはかなり簡潔に書けていると思います。

ダブルディスパッチしたくなったら、言語を変更できないか考えてみてもいいかもしれませんね。

なごやまつりでF# Type Providerについて(?)話してきた

F# Excel

してきました。 あれだけの人数が集まって、F# 知らない人が全然いないとかすごい勉強会でしたね。

Excel方眼紙、どうにかしたいものですね。 今回作った(作りかけ)コードは、GitHubに置いてあります。

ExcelHouganshi.TypeProvider

現実と戦うためのRealWorldsというorganizationを作ったので、「これも入れて！」というのがあれば考えます。 今のところ、みずぴーさんの作ったblockdiagcontrib-excelshapeもRealWorldsでホストしています。

飛ばしたところをちょっと補足つけて説明します。

TypeProviderのつくりかた

37枚目です。

TypeProviderは、 チュートリアル : 型プロバイダーの作成 (F#) をやれば作れるようになります。 このなかで、「ProviderTypes API」と呼ばれているものがありますが、 これはF#3.0 Sample Pack のSampleProviders/Sharedの中の「ProvidedTypes-xxx.fs(i)」です。 これをプロジェクトにコピーして使いましょう。 01～04とheadがありますが、headを使えばいいでしょう。

なぜコピーかというと、様々な型がinternalとなっているためです。 全部publicにしてもいいのですが、他の多くのプロジェクト(FSharpx, FSharp.Dataなどなど)がコピーして使っているため、 それに倣っておくのがいいでしょう。

基本的にはスライドでもある通り、ProvidedTypeDefinitionオブジェクトに対してメソッドやプロパティを追加していくことになります。 今回のコードだと、addCtorやaddMembersが該当箇所になるので、気になる方は追ってみましょう。

TypeProviderのデバッグ

38枚目です。

TypeProviderをVSでデバッグしながら開発する場合は、 TypeProvider用のソリューションとデバッグ用のソリューションを分割する必要があります。 これを同じにしてしまうと、VSがdllをつかみっぱなしになるためにビルドが出来なくなってしまいます。

今回スライドに書いた方法であれば、TypeProvider用のソリューションファイルと同じ場所にデバッグ用ソリューション(Sample.sln)を置くだけで誰でもVSでTypeProviderのデバッグが出来るようになります。 注意点を上げるとすると、デバッグ用ソリューションからはプロジェクト参照ではなく、dllを直接参照する必要がある、という点です。 プロジェクト参照してしまっては結局dll掴みっぱなしになってしまいますからね。

あとは、VSを2つ以上立ち上げても平気な環境がないとたぶん厳しいです。

小技

39枚目です。

HideObjectMethodsプロパティについては、上で紹介したチュートリアルに載ってますが、見落としていたので紹介です。 LangExtでは、EditorBrowsable属性を付けて回って頑張ってるわけですが、TypeProviderでProvideすればこのプロパティをtrueに設定するだけでいいんですね・・・便利。

ファイル存在チェックを導入する前は、GUID生成してファイル名にしてました。 これだと、一回コンパイルを走らせるだけで5ファイルくらい生成され、 リアルタイムでコンパイルが走っているためにその後もどんどんファイルが増えていく、という事態に陥りました。 そこで、コンパイルするファイルの中身をSHA-1ハッシュにかけ、ファイル名をそれにすることで存在チェックできるようにしました。

最後のはまぁ、えっと、その。

.NET基礎勉強会でラムダ計算の発表をしてきた

F#

もう一か月以上も前の話ですが、.NET基礎勉強会で(型無し)ラムダ計算の話をしてきました。 .NETと言えばF#、F#の基礎と言えばラムダ計算！ですよね！ 発表資料はこちらです。

当日は2 + 3が分からないと好評(?)でした。 当時の様子はこんな感じです。

反省して、発表資料に計算過程を追加しておきました。

掛け算も追加してあるので、追ってみてください。 掛け算は、4から5に行くときに、3を表すラムダ項が増殖しているのがミソです。

実際にノートに書くのがおすすめですけど、カッコの対応が分からなくなる恐れがあるので、 色鉛筆使うのがおすすめです。

引き算や割り算、型付きラムダ計算など気になる方は、

型システム入門 −プログラミング言語と型の理論−

型システム入門 −プログラミング言語と型の理論−

  • 作者: Benjamin C. Pierce,住井英二郎,遠藤侑介,酒井政裕,今井敬吾,黒木裕介,今井宜洋,才川隆文,今井健男
  • 出版社/メーカー: オーム社
  • 発売日: 2013/03/26
  • メディア: 単行本（ソフトカバー）
  • クリック: 68回
  • この商品を含むブログ (8件) を見る

をどうぞ！ 型付きラムダ計算以降も楽しいですよ！

NullableとOptionの違い

C#

このエントリの最新版はGithubにあります。

Optionそのものについてのエントリは書く必要ない(世の中に有用なドキュメントが山ほどあるから)かな、 と思っていたのですが、Nullableとの違いについてはそれなりに需要がありそうなので書いておきます。

ちなみに、個人的な嗜好によりOptionを持ち上げ、Nullableを下に扱う感じになっていますが、Nullableも(仕方なく)使うことはあります。 特別な理由がなければNullable使わずにOptionを使う、ということでもありますが、そこは一つよろしくお願いします。

Nullableとは

C#ではnullは参照型でしか使えませんでした。 Nullableは、この制限がない(ように見えるよう特別扱いされている)唯一の値型です。 ジェネリック型になっており、任意の値型を扱うことが出来ます。

// Nullable<int>はint?と書ける
int? x = 42;   // 値がある
int? y = null; // 値がない

// こちらは参照型なので、Nullable型ではない
string a = "hoge"; // 値がある
string b = null;   // 値がない

Optionとは

Optionは、「nullよりも安全に値がないことを表せる」ものです。 ジェネリック型になっており、任意の型を扱うことが出来ます。

Option<int> x = Option.Some(42); // 値がある
Option<int> y = Option.None;     // 値がない

Option<string> a = Option.Some("hoge"); // 値がある
Option<string> b = Option.None;         // 値がない

このエントリでは、OptionはLangExtのOptionを指すものとします。

NullableとOptionの類似点

NullableもOptionも、structで実装されており、値を持っているかどうかを表すフラグと、値を保持しているという点で、構造は似ています。 しかし、似ているのは構造くらいで、目的や使い方などはかなり異なります。

NullableとOptionの違い

パラメータとして渡せる型の違い

Nullableは値型でもnullを扱えるようにするために作られたため、値型しか型パラメータに指定できません(参照型はそもそも最初からnullを扱える)。

Nullable<int> i = null;
// これはコンパイルエラー
//Nullable<string> s = null;
// そもそもこう書ける
string s = null;

それに対してOptionは、nullを置き換えるために作られているため、値型であっても参照型であっても型パラメータに指定することができます。

Option<int> i = Option.None;
Option<string> s = Option.None;
// もちろんこれはコンパイルエラー
//string s = Option.None;

また、Nullableはネストさせることができません(Nullable<Nullable<int>>や、int??はできない)が、Optionは出来る、という違いもあります。

表記上の違い

Nullableは言語組み込みの機能なので、表記はとてもシンプルです。 また、値がある場合はその値が直接書けます。

それに対してOptionは、値がある場合でもOption.Someの呼び出しが必須になるため、その分面倒です。 任意の型からそのOption型への暗黙の型変換を提供すればこれは解決できるのですが、 これには問題もあるため、LangExtでは提供していません。

その理由については、 Optionの設計 で述べていますので、後で(NullableとOptionの違いを理解したうえで)読んでみてください。

設計方針の違い

Nullable型は値型でnullを扱えるようにすることを目的としています。 単に値がない状態を表せればよく、それをどう扱うかには興味がありません。 そのため、Nullableが出来るのは基本的には

  • nullかどうかのチェック
  • 値の取り出し

の2つだけです。

それに対して、Option型はどうやって値がない状態を上手に扱うかが最大の興味です。 そのため、Optionに対しては様々な操作が可能です。 しかし、Nullableには用意されている「値の取り出し」は、Optionでは簡単にはできないようになっています。

値が取り出せるのは一見便利に見えます。 しかし、値がない場合に値を取り出そうとした場合にどうすればいいかを考える必要があります。 Nullableの場合、

  • 値がない場合に例外(InvalidOperationException)を投げるValueプロパティ
  • 値がない場合にデフォルト値を返すGetValueOrDefaultメソッド
  • 値がない場合に引数で指定した値を返すGetValueOrDefaultメソッド

の3つの方法を用意しています。 Valueプロパティは一番使うのが簡単なので一番多用されがちな方法となりますが、nullチェックが強制されるわけではないため、気を抜くと簡単に例外が投げられてしまいます。 Nullableは「どうやって値がない状態をうまく扱うか」に興味がないため、 この設計選択は妥当と言えるでしょう(ただ、Nullableの場合と参照型の場合とで投げられる例外が違うのがいいことなのかどうかは場合によると思います)。

static string F(int? x)
{
    return x.Value.ToString(); // xがnullならInvalidOperationExceptionが発生
}

しかし、「どうやって値がない状態をうまく扱うか」が最大の興味であるOptionでは、簡単に例外を投げるわけにはいきません。 そこで、Optionがとる方針はこうです。 「値の取得は禁止して、値を受け取った後の処理と、値がなかった(値が受け取れなかった)場合の処理を渡してもらいOptionの中でそれを振り分ければいい！」

static string F(Option<int> x)
{
    // 値がない場合も考慮することを強制するAPI
    return x.Match(
      Some: i => i.ToString(),
      None: () => { throw new Exception(); }); // 今回は例外を投げるだけでいいので、Nullableより面倒
}

こうすることで、ついうっかり値がない考慮が漏れてしまうという失敗を防ぐことができるのが、OptionとNullableの最も大きな違いです。

値がないことの伝搬

Tと演算可能なUがあった時、T?とUも演算可能です。 そのため、以下のプログラムは「42.1」を表示します。

int? x = 42;
double? y = x + 0.1;
if (y != null)
    Console.WriteLine(y);

ここで、xがnullだった場合はどうなるでしょうか。この場合、nullが伝搬することになります(比較演算子の場合はまた違います)。 つまり、yもnullになります。

int? x = null;
double? y = x + 0.1;
if (y != null)
    Console.WriteLine(y); // yがnullなので表示されない

では、以下の例ではどうでしょう？

int? x = null;
string y = x + "aaa";
if (y != null)
    Console.WriteLine(y);

この場合、なんと「aaa」が表示されます。 参照型の場合、(自分で定義しない限り)nullの伝搬は起こらなかったので、nullに文字列を加えたときの動作は特別なものではありませんでした。 しかし、Nullableにnullの伝搬を導入したせいで、Nullableに関してはnullに文字列を加えたときの動作が特別なものに見えるようになってしまっています。

Optionでどうなるかを見てみましょう。 Optionで同じことをするためには、Optionのままでは演算できないため、MapとIterを使います。 これらの関数は、内部でMatchを使って実装されています。

public static Option<U> Map<T, U>(this Option<T> self, Func<T, U> f)
{
    // fが呼び出されるのは値がある(Someの時)だけ
    return self.Match(
      Some: v => Option.Some(f(v)),
      None: () => Option.None);  // Noneは常に伝搬する(文字列が特別扱いされるなどはない)
}
public static void Iter<T>(this Option<T> self, Action<T> act)
{
    // actが呼び出されるのは値がある(Someの時)だけ
    self.Match(
      Some: v => act(v),
      None: () => { });
}

これらを使うと、「値があるかどうかわからないものに0.1を加え、値があればその結果を表示する」コードはこう書けます。

Option<int> x = Option.Some(42);
x.Map(_ => _ + 0.1)
 .Iter(y => Console.WriteLine(y)); // 「42.1」と表示される

Option<int> x = Option.None;
x.Map(_ => _ + 0.1)
 .Iter(y => Console.WriteLine(y)); // 何も表示されない

値があるかどうかの判定をユーザーコード側で行っていない(MapとIter内部で行っている)という違いはありますが、ここまでの動作はNullableと同様です。 Nullableと違うのは、文字列の結合も他の場合と同じような動作をする点です。

Option<int> x = Option.None;
x.Map(_ => _ + "aaa")
 .Iter(y => Console.WriteLine(y)); // 何も表示されない

Nullableでは、T型でできることは、極力T?型でもできるように考えられています。 しかし、そのせいで統一性が崩れてしまっています。

それに対して、OptionはT型にできる操作をOption[T]型に対して提供していません(提供できません)。 T型とOption[T]型は完全に別の型であり、Optionはあくまで「値があるかないかの表現」以上のことは行いません。 そのため、Optionが保持する値に対して処理を行いたい場合は、MapやIterのような高階関数を使って値を受け取る関数を渡すことになり、 すべての処理が統一性を保っています。

クエリ式の対象にできるかどうか

クエリ式でOptionを扱うと、「値がない場合」を意識せずに処理が記述でき、非常に便利です。

// Option<int> TryGet(string key); があったとする
var res =
  from x in TryGet("x")
  from y in TryGet("y")
  select x + y;

この程度の例なら、Nullableでも問題なく扱えます。

// int? TryGet(string key); があったとする
var x = TryGet("x");
var y = TryGet("y");
var res = x + y;

しかし、参照型が混じると途端に厳しくなります。

// Optionの場合は特に何も変わらない
var res =
  from x in TryGetInt("x")
  from y in TryGetStr("y")
  select x + y; // x(の文字列表現)とyを連結

// Nullableと参照型との演算ではnullが伝搬しないので、nullチェックが必要になる
var x = TryGetInt("x");
var y = TryGetStr("y");
var res =
  // うっ・・・
  x == null || y == null ? null
                         : x + y;

これを回避したくて、Nullableにもクエリ式を提供したくなります。 しかし、これらのケースすべてをカバーできるクエリ式を提供することは、C# のオーバーロード解決能力が低いため不可能です。 実際に実装してみると分かるのですが、T?だけを扱うようなクエリ式は提供可能です。 例えば、

// int? TryGet(string key); があったとする
var res =
  from x in TryGet("x")
  from y in TryGet("y")
  select x + y;

ここまでは可能です。 しかし、そこにT when T : classwhere T : classも扱えるようにしようとすると、オーバーロードが解決できないバージョンのSelectManyを書く必要が出てきてしまいます。

NullableとOptionの違い

Nullableは、nullチェックから逃れることを目的としていない時点で良くないアイディアです。 null参照の考案は10億ドル単位の過ちと、 考案者自らが認める過ちであるnullの適用範囲を広げてしまうNullableを、言語仕様(それどころかCLRにまで)に組み込んでしまうというのは、 個人的にはなんてセンスのない設計をしたんだ、と思ってしまいます。

それに対してOptionは、OOPの側面からみるとNullObjectをジェネリックの力を借りて汎用化したものであり、 非常に好ましいものです。 シグネチャ上で「値がないかもしれない」ことを表すことができるのも、ありがたいです(Nullableは出来るが、参照型ではできない)。

構造は同じなのに、ここまで正反対の意見になるというのは、ちょっと面白いですね。 この違いは、主に提供するAPIから来ており、「値を(簡単には)取り出せない」という制限がOptionの良さの根源にあるというのは、心に留めておいてほしいです。 何でもかんでもできるAPIが常によいというわけではないのです。

(おまけ)Optionからの値の取り出し

・・・とは言うものの、Optionからさくっと値を取り出したい場合があるのも事実です。 例えば、「ここでは絶対値があることが分かりきっている」というような場合です。 そのような場合でも、通常は値がなかった場合の考慮が必要ですが、LangExt.Unsafe名前空間をusingすることで、Optionから直接値を取り出せる関数が使えるようになります。

LangExtのOptionに限らず、たいていのOptionの実装には、このような「直接値を取り出す」関数が提供されています。 そればかりか、場合によっては他のAPIと一緒にこの関数を紹介してしまっている場合もあります。

しかし、Optionの目的を「安全に値がないことを表す」と置くのであれば、この関数をそのように紹介するのはよくないことです。 これを先に教えてしまえば、nullを知っている人の多くは「使いにくいnullだ」と思いながらOptionを使ってしまうことでしょう。

そういう事態を避けるためにも、Optionから直接値を取り出す関数は、Optionの目的や利点を語った後で教えるべきです。 場合によっては、教えないというのもアリでしょう。 それくらい、慎重に扱うべきものです。

LangExtでのOptionの設計

C#

このエントリの最新版はGithubにあります。

Optionの意味を理解していることを前提に、直和型をC#で実現する方法についてを説明し、 LangExtではどういう方針を採用しているのかと、その理由について明らかにします。

バリアント型のC#での設計方針

Optionなどのバリアント型(VBのVariant型のことではありません)をC#で実現する場合、大まかに次の2つの方針があります。

  • 型の階層で表現する
  • タグを判別する値を持つようにする

一つ目の方法は、Option(もしくはMaybe)型の実現方法としてよく使われている方法です。

     +-----------+
     | Option[T] |
     +-----------+
           △
           ｜
     +-----＋-----+
     |            |
+---------+  +---------+
| Some[T] |  | None[T] |
+---------+  +---------+
| - value |
+---------+

二つ目の方法は、LangExtのOption型が採用している方法です。

     +------------+
     |  Option[T] |
     +------------+
     | - hasValue |
     | -   value  |
     +------------+

これらの特徴を、Option型を実現する場合を例に見ていきます。

型の階層で表現する方法

バリアント型を型の階層で表現する方法は、実際にはOption型をinterfaceとして定義することが多いようです。 この方法では、Option型に対する操作はポリモーフィズムによって実現され、分岐は型階層に隠蔽されます。

public interface IOption<out T>
{
    bool HasValue { get; }
    IOption<U> Map<U>(Func<T, U> f);
    IOption<U> Bind<U>(Func<T, IOption<U>> f);
    T GetOr(T defaultValue);
}

public sealed class Some<T> : IOption<T>
{
    readonly T value;
    public Some(T value) { this.value = value; }

    public bool HasValue { get { return true; } }
    public IOption<U> Map<U>(Func<T, U> f)
    {
        return new Some<U>(f(this.value));
    }
    public IOption<U> Bind<U>(Func<T, IOption<U>> f)
    {
        return f(this.value);
    }
    public T GetOr(T defaultValue) { return this.value; }
}

public sealed class None<T> : IOption<T>
{
    public bool HasValue { get { return false; } }
    public IOption<U> Map<U>(Func<T, U> f)
    {
        return new None<T>();
    }
    public IOption<U> Bind<U>(Func<T, IOption<U>> f)
    {
        return new None<T>();
    }
    public T GetOr(T defaultValue) { return defaultValue; }
}

実際には拡張メソッドで提供するメソッドについては、その中で分岐が発生しますが、 一番コアの部分はifによる分岐を(それがいいことかどうかは置いておいて)完全に排除できます。

この方法は、オブジェクト指向プログラミング的な方法であり、 オブジェクト指向プログラマにとっては自然であり、美しい解決方法でしょう。

タグを判別する値を持つ方法

Option型にはSomeとNoneという2つのラベルがあります。 これを判別するのに必要な情報は1bitでいいため、boolを使えば十分です。

public struct Option<T>
{
    readonly bool hasValue;
    readonly T value;
    public Option(T value)
    {
        this.hasValue = true;
        this.value = value;
    }

    public bool HasValue { get { return this.hasValue; } }
    public Option<U> Map<U>(Func<T, U> f)
    {
        if (this.hasValue)
            return new Option<U>();
        return new Option<U>(f(this.value));
    }
    public Option<U> Bind<U>(Func<T, U> f)
    {
        if (this.hasValue)
            return new Option<U>();
        return f(this.value);
    }
    public T GetOr(T defaultValue)
    {
        return this.hasValue ? this.value : defaultValue;
    }
}

バリアント型をタグを判別する値を持つことによって表現する方法は、先の方法に比べると泥臭い方法に見えます。 LangExtでは、この2つの方法のメリットとデメリットを考えたうえで、泥臭く思える後者の方法を採用しています。

それぞれの利点と欠点

まずは、型の階層で表現する方法の利点を考えてみます。

  1. Noneの場合に余分なフィールドを持つ必要がない
  2. SomeやNoneにも型を与えることになるため、「Someだけを受け取れるような関数」のように、柔軟な関数を定義可能
  3. (Optionをinterfaceとすることで)型パラメータにoutが指定できる
  4. 実装が綺麗に書ける

特に、1つ目はラベルが多くなればなるほど効果を感じることができる利点でしょう。

2つ目も、Optionではそれほどメリットを感じないかもしれませんが、 例えばファイルとディレクトリを扱う型階層を作った場合などは大きな利点になります。

3つ目はoutを付けることのできないようなものも考えられますが、Option型の場合には付けることができます。 TがSを継承している場合に、Option[T]がOption[S]として使えるというのは、オブジェクト指向言語においては非常に魅力的です。

4つ目は、実際にミニマムな実装をしたコードを見ても、ifが全く出てこないため、オブジェクト指向プログラミングとして綺麗なコードと言えるでしょう。

では、タグを判別する値を持つことによって実現する方法の利点はどうでしょう。

  1. Option型の変数に対してnullを入れることを防げている(structのため)
  2. 勝手に独自のラベルを作ることができない(型階層で実現する方法の場合、IOptionを実装することで可能)

の2つです。 後者は一概には利点/欠点と判断できるものではないですが、少なくともOption型には不要な機能であり、それができてしまうと色々面倒です。

また、前者の利点は絶大です。 Option型が達成したいのは、「nullの排除」です。 にもかかわらず、型階層による実現方法では、「IOption[T]型の変数そのものにnullを入れられてしまう」という可能性を排除できません。

これは、別に

IOption<string> opt = null;

という直接的なコードが書かれてしまう、ということではありません。 そうではなく、例えばIOption[T]を受け取るような関数に「とりあえず」nullを渡しておいて、「後で」直そう、と思って忘れていたような、 「うっかりnull」の方を心配しています。

LangExtの公開以前のかなり初期のバージョンでは、型階層によってOptionを実現していました。 しかし、この手のミスがそれなりに発生したため、設計方針を切り替えたという経緯があります。

もちろん、これを単体テストやDbCによって排除すべきだ、という立場もあるでしょう。 しかし、単体テストで見つけるよりもコンパイル時に見つけた方が発見のコスト(単体テストではテストコードを書いたり、実行したりが必要)も修正のコストも小さくなりますし、 そもそも考慮漏れを起こす心配がありません。

また、DbC(というかCode Contracts)で「この型の変数にはnullは格納できない」のような契約の書き方がわかりませんでした。 もしかすると方法はあるのかもしれないですが、LangExtではCode Contractsでどうこうする、という方向は諦めています。

どちらを採用するか

これらの利点と欠点を考えたうえで、LangExtではnullを徹底的に排除するために、タグを判別する値を持つ方法を採用しました。 これにより、LangExtのOptionでは(変数にしろ、Optionの高階関数に渡された関数の引数にしろ)nullが来ることは一切考慮する必要がないという安心感を獲得しています。

Option以外のバリアント型

これまで考えてきたのは、あくまでOption型を実現する場合についてです。 そのため、Option以外のバリアント型もすべてOption型と同じように実装するかどうかは別問題です。

Option型に失敗時の原因も持たせることができるように拡張したResult型では、Option型と同じ方針を採用していますが、 Option型と違ってstructにすることができませんので、今後のバージョンで型階層による実現方法に変更される可能性もあります。 ただし、あくまで実現方法のみの変更になるため、変更があった場合でもユーザコードは修正不要です。

Option型の値の生成

Option型の値を生成する方法としては、コンストラクタを呼び出すのが.NETプログラマとしては最もわかりやすいでしょう。 しかし、この方法では常に型パラメータを明示する必要があるため、面倒です。

public void F(Option<string> opt) { ... }

F(new Option<string>("hoge")); // Some "hoge"
F(new Option<string>());       // None

これを解決するために、ほとんどのライブラリのOptionと同様、staticメソッドを提供しています。

F(Option.Some("hoge"));

さらに、LangExtではこれに加えて、型引数なしでNoneを使うことができるようにしています。

F(Option.None);

Option.NoneはOption[Placeholder]型のNoneを生成するようになっており、 Option[Placeholder]型から任意のT型のOption型への暗黙型変換を提供することでこれを実現しています。

それ以外の方法

それ以外の方法として、任意のT型からOption[T]への暗黙型変換を提供することも考えられます。 また、nullを任意のT型のOption型のNoneに暗黙変換を提供するのも便利かもしれません。

LangExtでは、これらの変換を提供することも考えましたが、どちらも却下しました。

任意のT型からOption[T]型への暗黙の型変換を提供しない理由

これを提供しないのは、nullの扱いにあります。

public Option<string> F(string str)
{
    return str;
}

さて、単純なコードではありますが、strにはnullが格納されている可能性があります。 その場合にこのコードは何を返すべきでしょうか？Some nullでしょうか？それとも、Noneでしょうか？

これは暗黙の型変換の仕様さえ覚えてしまえばそれでいいのですが、 それを知らない人が「こっちだ」と思い込んでしまう可能性は捨てきれません。

そのため、LangExtではこの変換を提供していません(さらに、LangExtではOption.Some(null)は例外を投げるようになっており、nullを格納するSomeは作ることができません。これによって、Optionの高階関数に渡す関数の引数にnullが渡されることがないことも保証しています。もしSome nullのようなことがしたいのであれば、Optionをネストするか、別の型を作るようにしてください。)。

public Option<string> F(string str)
{
    return Option.Some(str);
}
// もしstrがnullの場合にNoneが返したい場合は、明示的に書く
public Option<string> G(string str)
{
    if (str == null)
        return Option.None;
    return Option.Some(str);
}

nullを任意のT型のOption型のNoneに暗黙変換しない理由

これには、上の問題以上の問題があります。

例えば、当初はOption[string]を受け取っていた関数Fの仕様が変わり、stringを受け取ることになったとした場合、 nullをNoneに暗黙変換している個所はコンパイルエラーにならずに単にnullを渡してしまうことになります。

// 暗黙の型変換を提供していれば、F(Option<string> opt)でもF(string str)でもコンパイルできてしまう
F(null);

実はこのような暗黙の型変換を公開前のLangExtは提供していたことがありました。 その当時はまだOption.Noneとは書けず、Option.None<string>()のように書く必要があったこともあり、 手軽に書けるnullからの変換を多用していました。 しかしというか、やはりというか、上のような問題がそれなりに発生し、 さらにOption.Noneという書き方ができるようになったため、nullをNoneとして扱う機能は削除しました。

クエリ式への対応

Option型をクエリ式に対応させる最も手軽な方法は、IEnumerable[T]を実装することでしょう。 そうすれば、IEnumerable[T]に対して定義されたSelectやSelectManyによって、Optionをクエリ式で扱えるようになります。

しかし、この方法では最終的に得られる型がOption[T]ではなくIEnumerable[T]になってしまいます。 そのため、LangExtではOption.QueryExpr.csでOption用のクエリ式用メソッドを提供しています。

IEnumerable[T]を実装していないのは、Option型をIEnumerable[T]として使いたいことがないからです。

match式の模倣

探した限りはあまり他で同じようなことをやっているライブラリがなかったのですが、 LangExtは(F#のような)match式をある程度模倣するMatchメソッドを提供しています。

int F(Option<string> opt)
{
    return opt.Match(
        str => int.Parse(str), // 値があった場合の処理
        () => -1);             // 値がなかった場合の処理
}

また、名前付き引数を使って、以下のように記述することもできます。

int F(Option<string> opt)
{
    return opt.Match(
        Some: str => int.Parse(str), // 値があった場合の処理
        None: () => -1);             // 値がなかった場合の処理
}

名前付き引数なので、順番を入れ替えることもできます(Match関数で名前付き引数を使うアイディアは、ころくんのつぶやきから借りています)。 このようなMatchメソッドは、Optionに限らず便利に使えるため、提供できる場合は提供しておくといいでしょう。

LangExtでは、Optionのほかに、ResultやTupleでもMatchメソッドを提供しています。 シーケンスに対しては実験的に実装してみた ものの、このままでは複雑すぎて使い物にならないので、アイディア募集中です。

Optionから値を取り出す方法

Option型のオブジェクトから値を取り出す操作(GetメソッドやValueプロパティ)を提供しているライブラリは多くあります。 しかし、これを提供してしまうと、せっかく「値がないことの考慮」を強制できるOptionの利点を損ねてしまいます。 そのため、LangExtではLangExt名前空間をusingしただけでは、Optionから直接値を取り出すことは出来ないようになっています。

LangExtOptionから値を取り出すには、デフォルト値を指定するGetOrメソッド(もしくはその派生のGetOrElseメソッド)を使うか、 LangExt.Unsafe名前空間をusingして(危険なコードを書くと宣言したうえで)GetValueメソッドを使います。

現在のバージョンのLangExtでは、Unsafe名前空間の中にOptionクラスを格納しているため、 Unsafe名前空間をusingしてしまうとOptionモジュールが解決できなくなってしまうという問題があります。 次のバージョンでは、Unsafe名前空間の中のOptionクラスは、UnsafeOptionという名前に変更予定です。

また、現在のバージョンではNoneの場合に例外を投げずにdefault(T)を返すものしか提供されていませんが、 今後のバージョンでは例外を投げるメソッドも追加予定です(名前はおそらくGetになります)。