ちなみに、判別共用体で複数の値をタプルを使わずに定義した場合、タプルによる構築はできるけど、タプルによる分解はできないという違いがあります
> type t = Hoge of int * int;;
type t = | Hoge of int * int
> let tpl = 1, 2;;
val tpl : int * int = (1, 2)
> Hoge tpl;;
val it : t = Hoge (1,2)
> let (Hoge tpl) = it;;
let (Hoge tpl) = it;;
-----^^^^^^^^
stdin(5,6): error FS0019: このコンストラクターには 1 個の引数が適用されていますが、必要なのは 2 個です
つらい
あ、ミスって消しちゃった・・・
editしようとしてdeleteおしてしもた
上記エントリに関しての指摘をいくつか連投します。
まず、パターンマッチの網羅チェックについてですが、「不足の検出」を前面に押し出していますが、個人的には「到達しないケースの検出」も不足の検出と同じくらいに重要だと思っています
不足している場合は実行時に例外がでますが、到達しないケースの検出は実行時に例外も出ないためより重要と言えるかも
次に、
enumの定義としてtype Modes = LightMode | StandardMode | ...としていますが、これだとenumではなく判別共用体(すべてのケースが値を持たない判別共用体)になります。
F#では
enumはすべての値を=で指定する必要があります。
つまり、コンパイラは他の値の考慮が足りないとして警告を出します。
次に、F#のタプルですが、
Item1やItem2によるアクセスはできません
System.Tuple<...>で表されてはいるのですが、別物と考えておいた方が色々といいかもしれません。
次は細かいところですが、F#のリストは読み取り専用の順方向リンクリストのようなものではなく、読み取り専用の順方向リンクリストそのものです。
type 'a list =
| []
| (::) of 'a * 'a list
こんな定義のイメージです
演算子であれば
( <op> )のようにして関数化可能ですが、どちらも不可能です
:?はパターン、[| ... |]は配列式を構成する文法です
到達しないケースの検出、は書いてる途中で気がついてました。改訂するときに盛り込んでみます
次に複数の値を持ったケースを持つ判別共用体の定義方法ですが、
// タプルで定義
type Node =
| Element of (string * (Node seq))
| Text of string
// タプルを使わずに定義
type Node =
| Element of string * Node seq
| Text of stringの2種類があって、後者の方がより効率的な型を生成します。
タプルを使うと、生成される型のフィールドには当然タプルが現れますが、タプルを使わない場合はそれぞれ独立したフィールド(上の場合だと2つのフィールド)が直接生成される型のフィールドとして定義されます。
効率以外にもコード上に現れてくる違いとして、タプルを使わずに定義した場合は
match式でタプルとして受け取れない、というものがあります。
うっ... markdownだった
次に、バナナクリップについてですが、これを「演算子」とするのはF#の演算子と紛らわしいため、できれば避けたい用語です。