NGK2014Bで発表してきた

NGK2014Bで、FCellという製品紹介の発表をしてきました。 詳細は、発表資料よりもその中で紹介しているデモを参考にしてください*1

FCellと類似した(?)ものとしては以下のようなものがあります。

COMは置いといて、そのほかのものとFCellがどう違うかということを軽く説明しますね。

NPOIやEPPlusとの違い

NPOIやEPPlusは、基本的に「Excelを外から操る」ためのライブラリです。 こいつらはこいつらで便利なんですが、「Excelを中から操る」ことはできないので、こいつらで置き換え可能なVBAというのはほんの一部なんですね。

それに対してFCellは、ユーザ定義関数(UDF)をF#*2で定義できるのです。 そして定義したUDFは当然のようにExcel内で使えます。

Excel DNA

Excel DNAも、F#*3でUDFを定義できます。 しかし、Excel DNAは「Excelの外部」で動くものであり、Excelファイルにコードを埋め込めないです。

それに対してFCellは、Excelファイルにコードを埋め込めます。 埋め込むという選択肢のみであればVBAと変わらないのですが、埋め込まずに外に出す、ということもできます。

VSTO

VSTOは、UDFを定義する程度のものにはフォーカスしておらず、アドイン開発に特化したものという認識です。 そのため、小回りが利かないという欠点を持ちます。 また、Excelファイルにコードを埋め込むのもできないようです。

それに対してFCellは、UDFを定義する部分から、UIをカスタマイズする部分までをターゲットにしているため、非常に小回りが利きます。 F#を利用する場合であれば、Excelに統合されたF#エディタが使える*4ため、VBAと同じ感覚で使えるのが大きな利点です。

この辺りは、棲み分けの話だと思うのですが、VSTOは中規模から大規模なものに、FCellは小規模から中規模なものに使うのがいいのでは、と思います。

VSTOには詳しくないので間違ったことを言っているかもしれないです。間違っていたら指摘ください。

FCellに足りない部分

VBAの最大のメリットは、ユーザの操作を記録してそれをマクロとして使いまわしたり、生成されたコードをベースに開発したりできる点にあると思っています。 FCellは現状それができませんので、Excel利用者のものというよりはやはり開発者のためのものになっています。 今後、これが改善されてExcel利用者も気軽にFCellが使えるようになれば、と願っています。 お金の話は置いといて。

*1:ちなみに、当日はでも動画を流したのではなく、自分で作ったデモを実際に動かしました

*2:2.0からは、C#VBといった言語もサポートするようになりました

*3:もちろんC#VBも使えます

*4:補完機能やエラー表示機能も持っています

Re: FSharperならこう書く(A Poker Game Program) #FsAdvent

FSharperならこう書く(A Poker Game Program) #FsAdventというエントリがF# Advent Calendar 2014の8日目の記事として公開されました。 この記事自体は、主に設計よりな話をしていますが、ここでは実装寄りの話を中心に、 勝手に添削してみました。 また、記事の中に書かれていた疑問にも回答したりしています。

添削その1(全体)

型とモジュールの名前

元のコードでは、モジュールの中にTという型を入れるスタイルのようです。

(* 柄 *)
module Suit =
    (* 柄 *)
    type T = | Spade | Heart | Diamond | Club
    (* 全ての柄 *)
    let values = [Spade; Heart; Diamond; Club]

自分も昔はこんな感じにしていたのですが、現在のところこのスタイルはやめ、モジュール名と型名に同じ名前を付けるスタイルを採用しています。

type Suit = Spade | Heart | Diamond | Club

[<CompilationRepresentation(CompilationRepresentationFlags.ModuleSuffix)>]
module Suit =
  let values = [Spade; Heart; Diamond; Club]

なんでかというと、

  • F#には高度なモジュールシステムがないので、あまり意味がない
  • 同じ型名が(モジュールが別だとしても)複数あると、複数型推論が微妙になる

あたりが大きな理由です。 CompilationRepresentationとかCompilationRepresentationFlags.ModuleSuffixとか面倒ですが、覚えてしまえばどうということはないですよ。

回答その1(Card)

レコード生成の制限

こんな疑問が書かれていました。

番号は、1から13に含まれない値は生成できないようにしたいので、classになりそうです。 classにするとinterfaceの実装が煩わしいところですが、constructorを制限しようと思うと、レコードや判別共用体では厳しそうです。 もし他に良い方法をご存知の方がいらっしゃったら教えてください。

これに対する回答としては、2通りあります。

  • シグネチャファイルで型の実装を隠蔽する
  • privateで型の実装を隠蔽する

前者はfsiファイルを書かなければならず、面倒というのと、型の実装を隠蔽してしまうとcomparison制約とかも自分でやる必要が出てきてそれも面倒なので、今回はお手軽にprivateで隠蔽する方法を紹介します。 元のコードはこんな感じです。

(* 番号 *)
module Number =
    type T(value:int)=
        do
            (* 数値範囲チェック *)
            if not (min <= value && value <= max)
                then failwith "The Number is required 1 to 13."

これを、型名を変更しつつレコードで実現してみましょう。

type Number = private {
  Value: int
}

[<CompilationRepresentation(CompilationRepresentationFlags.ModuleSuffix)>]
module Number =
  let min = 1
  let max = 13
  let value x = x.Value
  let create x =
    (* 数値範囲チェックをこちらに書く *)
    if not (min <= x && x <= max) then
      failwith "The Number is required 1 to 13."
    { Value = x }

こうすることによって、それを含むモジュール(ここではファイルと思ってください)の外からは{ Value = 42 }のようには書けなくなりますし、当然let f (x: Number) = x.Valueというコードもコンパイルエラーになります。 パターンマッチも(それを含むモジュールの外では)できなくなるので注意してくださいね。

IComparable

レコードにしたため、IComparable等の実装が不要になりましたが、元のバージョンではこれらを実装していました。 さて、これらを実装しているのはいいのですが、実は大小比較だけしたいだけであれば実装するインターフェイスはかなり減らせます。

type T(value: int) =
  (* snip *)
  member this.Value = value
  interface System.IComparable with
    member this.CompareTo(other) =
      match other with
      | :? T as x -> compare value x.Value
      | _ -> failwith "other is not T"
  (* snip *)

これだけで、警告は出るものの=<も他の比較演算子も使えるクラスになります。 このあたりは、言語仕様(PDF)の8.15.3を参照してください。 ざっくり説明すると、System.IComparableを明示的に実装している場合、Equalsメソッド

override x.Equals(y : obj) =
  ((x :> System.IComparable).CompareTo(y) = 0)

という実装が生成されるという感じです。 CompareToジェネリック版ではなく非ジェネリック版が呼び出されるので、System.IComparableだけ実装すればよい、ということですね。 また、compare関数を使えばCompareToメソッドは簡単に実装できます。

ただし、これに頼る場合は警告が出るみたいです。言語仕様にはその記述はなかったように思いますが・・・

添削その2(Deck)

単純なfor式

山札を表すDeckモジュールのdeck_without_joker関数ですが、一番内側のfor式はyieldしか含みません。

(* デッキ(ジョーカー抜き) *)
let deck_without_joker = List.ofSeq(seq{
        (* シーケンス式の二重ループでNumberとSuitの組み合わせを列挙する *)
        for num in Card.Number.min .. Card.Number.max do
        for suit in Card.Suit.values do
            yield { Card.Number = Card.Number.create num; Card.Suit = suit }
    })

このような場合、do yieldの代わりに->が使えます。 名前もlikeThis形式に変えておきましょう。

let deckWithoutJoker =
  List.ofSeq (seq {
    for num in Card.Number.min .. Card.Number.max do
    for suit in Card.Suit.values ->
      { Card.Number = Card.Number.create num; Card.Suit = suit }
  })

添削その3(List)

take関数の名前

既存のListモジュールに足りない処理を追加するために、独自のListモジュールを作っています。 その中で、takeという関数を追加しているんですが、これは標準のtakeを隠してしまううえ、やっていることもtakeではない気がします。

やっていることは、countでのリストの分割ですので、splitAtがいいでしょう。 名前は、Hoogleで探しました。 また、optionを返す関数はF#ではtryプレフィックスを付けるのが慣習ですので、trySplitAtとしてみました。

let trySplitAt count list =
  let rec loop i acc tail =
    if i = count then Some ((List.rev acc), tail)
    else match tail with
         | [] -> None
         | h::t -> loop (i + 1) (h::acc) t
  loop 0 [] list

tail |> functionとしている部分は、好みもありますが、個人的にはmatch tail withの方が好きなのでその部分も変更してあります。

また、Deck.pickoptionを返すので、Deck.tryPickにしました。

回答その2(Hand)

単一ラベルの判別共用体

こんな疑問がありました。

単一ラベルの判別共用体ってどうなのでしょうか。

これは、ありだと思います。 FsControlを使うと、単一ラベルの判別共用体を多用するようになります(そうじゃない)。

添削その4(Hand)

System.String.Join

.NETの便利関数にSystem.String.Joinというのがあるのですが、 これはBasis.CoreのStr.joinを使いましょう。 嘘です。Stringモジュールのconcat関数を使いましょう。

ToString

ToStringの呼び出しは面倒なので、string関数を使いましょう。 コードは2つ下を見てください。

List.toArray呼び出し

String.concat'T seqを受け取り、'T list'T seqなのでtoArrayする必要はありません。 コードは1つ下を見てください。

逆向きパイプライン演算子

ToStringの実装で、逆向きのパイプライン演算子を使っています。

(* CUIの選択肢表示用ToString *)
member this.ToString indexes = this |> function
    | Hand xs -> 
        xs
            |> List.map2 (fun x y ->
                    sprintf "[%s]:%s" y (x.ToString())
                ) <| indexes (* 逆向きパイプライン演算子<|はロマン *)
            |> List.toArray
            |> curry System.String.Join "/"

ここは、||>の出番です。

member this.ToString indexes =
  match this with
  | Hand xs ->
      (xs, indexes)
      ||> List.map2 (fun x y -> sprintf "[%s]:%s" y (string x))
      |> String.concat "/"

あ、curry関数は使わなくなったので削除しました。

引数の位置でのパターンマッチ

createBy関数やchange関数で、レコードや判別共用体のパターンマッチをしている部分が何か所かあります。

(* 山札から最初のcount枚を取得して手札を作り、残りの山札とペアにして返す。
  山札の枚数が足りない場合はNone
*)
let createBy deck =
    Deck.pick count deck
        |> Option.map (fun pickResult -> 
            (* let束縛のレコードパターン *)
            let { Deck.Picked = picked; Deck.Deck = d } = pickResult
            ((Hand picked), d)
        )

(* 手札のうちchangeCardsで指定されたカードを捨て、山札から同じ枚数を加え、残りの山札とペアにして返す。 *)
let change hand deck changeCards =
    Deck.pick (Set.count changeCards) deck
        |> Option.map (fun pickResult ->
            let { Deck.Picked = picked; Deck.Deck = d } = pickResult
            let hand = hand |> function
                | Hand xs -> xs |> List.filter (changeCards.Contains>>not)
            Hand (List.append picked hand), d
        )

これらは、引数の位置でパターンマッチすればいいので、こう書き直せます。

let tryCreateBy deck =
  Deck.tryPick count deck
  |> Option.map (fun { Deck.Picked = picked; Deck.Deck = d } -> ((Hand picked), d))
                  (* ↑ラムダ式の引数の位置でレコードを分解 *)

        (* ↓関数の引数の位置で判別共用体を分解 *)
let change (Hand xs) deck changeCards =
  Deck.tryPick (Set.count changeCards) deck
  |> Option.map (fun { Deck.Picked = picked; Deck.Deck = d } ->
                  (* ↑ラムダ式の引数の位置でレコードを分解 *)
      let hand = xs |> List.filter (changeCards.Contains >> not)
      Hand (List.append picked hand), d
  )

添削その5(Rank of Hands)

役の強弱

F#の話ではないですが、役の強弱がおかしい気がしますね。 一般的なルールに従って、修正します。

type Rank =
  | OnePair | TwoPair | ThreeCards | Straight
  | Flush | FullHouse | FourCards | StraightFlush | RoyalStraightFlush

型の別名

役判定関数モジュールで、Card.NormalCard arrayという型名を大量に使っています。 こういう場合、型略称を定義してしまうと楽でしょう。

type private Cards = Card.NormalCard array

pairwise

straightflushの判定に、前のカードと今のカードをペアにしたシーケンスを得るために、

xs
    |> Seq.ofArray
    |> (fun xs -> Seq.zip xs (Seq.skip 1 xs))
    |> Seq.forall (fun t -> (fst t).Number ++ 1 = (snd t).Number)

というコードが出てきます。 これは、Seq.pairwiseというそのままな関数があるので置き換えてしまいましょう。

cards
|> Seq.pairwise
|> Seq.forall (fun t -> (fst t).Number ++ 1 = (snd t).Number)

タプルを引数の位置で分解する

上のコードはラムダ式の中でfstsndを使っているので、これを引数の位置でのパターンマッチにしてしまいましょう。

cards
|> Seq.pairwise
|> Seq.forall (fun (x, y) -> x.Number ++ 1 = y.Number)

配列 vs リスト

型略称を用意したCardsは現在、配列です。 リストではなく配列にしたのは、

引数の型を配列にしたのは、インデックスでのアクセスが多そうだったから、という程度の理由です。

とありました。 しかし、リストでもインデックスでアクセスできるうえ、引数として渡される配列もしくはリストの要素数は、5です。 この部分がクリティカルに効いてくるとは思えないので、リストに変更しました。

type private Cards = Card.NormalCard list

もし問題が起こったら、この型略称の部分を戻して、呼び出し部分の型を変えればいいでしょう。

SequenceEqual

royalStraightFlushの判定で、System.Linq.Enumerable.SequenceEqualを使って判定していますが、 Listをそのまま扱えば=で比較できるので、変更してしまいましょう。

let royalStraightFlush (cards: Cards) =
  (straightFlush cards) && (
    let royal = [10..13]@[1]
    (cards |> List.map (fun x -> x.Number |> Card.Number.value)) = royal
  )

List.filter Option.isSomeしてList.map Option.get

Evaluator.evaluate等の関数で、List.filter Option.isSomeしてからList.map Option.getしている箇所があります。

evals
    |> List.map (fun f -> f x)
    |> List.filter Option.isSome
    |> List.map Option.get

こういった処理には、List.chooseという関数が使えます。

evals
|> List.map (fun f -> f x)
|> List.choose id

回答その3(Rank of Hands)

判別共用体の大小

判別共用体の大小に関して、

大小比較が定義順に依存するのはちょっとしたポイントです。ソースは忘れました。

とありました。 言語仕様を参照してみると、8.15.4に、

If T is a union type, invoke Microsoft.FSharp.Core.Operators.compare first on the index of the union cases for the two values, and then on each corresponding field pair of x and y for the data carried by the union case. Return the first non-zero result.

とあります。

  • 2つの値の共用体ケースのインデックスがMicrosoft.FSharp.Core.Operators.compareに渡される
  • 付随するデータがある場合、それらがMicrosoft.FSharp.Core.Operators.compareに渡される
  • 0ではない最初の値が返される

ということのようですね。 共用体ケースのインデックスは、定義順に振られる*1ため、大小比較が定義順に依存するのです。

添削その6(メイン処理)

リストの生成

input_choicesの生成に、リストリテラルを使っています。

let input_choices = ["a"; "b"; "c"; "d"; "e"]

好みはわかれるかもしれませんが、ここは

let inputChoices = ['a'..'e'] |> List.map string

のように、文字のリストを..で作ってから文字列化したほうが楽な気がします。

まとめ

テストとかしてない*2ので動くかどうかわからないですが、コード全体はGistに上げました。

元のコードがとても読みやすく素晴らしかったです。 引き続き、F# Advent Calendarをお楽しみください!

*1:言語仕様の8.5.4にTagsというネストした型が作られ、0から始まる整数定数が振られる、というようなことが書いてあります

*2:元のコードを書き換えていっただけ。変換の過程でバグが入った可能性は大。