Equality 制約

github.com

の実装のためのメモ（宣伝）。

型制約は F# における型安全をマスターするためには必須の知識であるため、細かい仕様も見落としてはならない。

型制約は F# 言語仕様書 4.0 の 5.2 Type Constraints に記述されている。

Equality制約

Equality制約は滅多に使用しないが、かなり緩い制約になっている。

標準ライブラリでは(=)、(<>)、hashにEquality制約がついている。

定義

こう書く。'aにEquality 制約を指定できる。

<'a when 'a : equality>

挙動

Equality制約はほとんどの型が満たす。

なぜならEqualsメソッドのデフォルトであるSystem.Object.Equalsがリファレンスを比較するようになっているため、 全てのオブジェクトはEqualisy制約を満たす事になっている。

このコードで確認できる。

type A() = class end
let test<'a when 'a : equality> (_: 'a) = ()
do test(A())

AはIEquatableを実装しないため、Equality制約を満たさないと予想するかもしれない。 実際には前述のとおり、Equality制約を満たす。

Equality制約を違反する型を定義するには、NoEqualityAttirbuteを型に付ける。

[<NoEquality; NoComparison>]
type B() = class end
do test(B()) // 型 'B' は 'NoEquality' 属性があるため、'equality' 制約をサポートしません

NoEqualityAttribute、CustomEqualityAttributeはComparison制約系の属性NoComparisonAttribute、CustomComparisonAttributeと組み合わせて使用する。 CustomEqualityAttributeを指定した場合はObject.Equals(obj)、IEquatable<_>、IStructualEquatableのどれかを実装しなければならない。

Equality制約を満たす条件は次の通り。1、2は言語仕様書に定義されている。3、4は実装を読んだ。

1. NoEqualityAttributeを持っていない型
2. 依存する型が全てEquality制約を満たす型
   1. レコード、判別共用体、構造体の型パラメータ、フィールドに使用される型すべて（クラスは対象外）
   2. System.Tupleの要素の型
   3. ジェネリック型のEqualityConditionalOnAttributeが指定されたパラメータ
3. 関数FSharpFuncではない型（つまりFunc、ActionはEquality制約を満たす）
4. CustomEqualityAttributeが指定された型

C# で定義された型や、.Net標準ライブラリの型はEquality制約を満たすと言える。

わかりにくい項目の補足をする。

ジェネリック型のEqualityConditionalOnAttributeが指定されたパラメータ

クラスの型パラメータにEquality制約を満たさない型を指定しても、Equality制約を満たすと判断される。

type C<'a>() = class end
do test (C<int -> int>())

型パラメータにEqualityConditionalOnAttributeを付けると、Equality制約の解決に使用されるようになる。

type C'<[<EqualityConditionalOn>]'a>() = class end
do test (C'<int -> int>()) // 型 '(int -> int)' は関数型なので、'equality' 制約をサポートしませ

CustomEqualityAttributeが指定された型

レコード、判別共用体、構造体に使う。依存する型がEquality制約を満たさなくても良くなる。

[<CustomEquality; NoComparison>]
type D<'a> = {
  Field: 'a
}
with
  override this.Equals(_) = true
  override this.GetHashCode() = 0

let f = fun () -> ()
do test({ Field = f })

EqualityConditionalOnAttributeと同時に使われた場合は、EqualityConditionalOnAttributeも考慮する必要がある。

次のような型を定義した場合は、

[<CustomEquality; NoComparison>]
type E<[<EqualityConditionalOn>]'a, 'b> = A of 'a | B of 'b
with
  override this.Equals(_) = true
  override this.GetHashCode() = 0

E<int, int -> int>という型はEquality制約を満たすが、E<int -> int, int -> int>は'aが関数であるためEquality制約を満たさない。

まとめ

実装するのがツライ

リンク

Equality and Comparison Constraints in F# | Don Syme's WebLog on F# and Related Topics

使いたくない型を見えなくする #FsAdvent

この記事はF# Advent Calendar 2015 - connpassの2日目です。

同僚へのイタズラネタを紹介したいと思います。 AutoOpenと組み合わせて混乱に陥れてやりましょう。 標準ライブラリの中には、古くなったり、挙動が紛らわしいという理由で使うべきではないクラスや関数があります。 どこかのサイトから当時は適切だった古いコードを参考にしてきて、うっかり使ってしまう人もいるでしょう。

こんな困った人のコードはコンパイルエラーにしてやる！

一部のメンバのみ制限する

例えば、System.Text.Encoding.UTF8プロパティとSystem.Text.UTF8Encodingクラスの2つで、BOMがどう扱われるか直ぐに言えますか？ System.Text.Encoding.UTF8はBOMが付きます。一方、System.Text.UTF8EncodingはコンストラクタでBOMの有無を指定できます。 BOMを扱わないシステムを扱っている場合は、System.Text.Encoding.UTF8をなるべく使ってほしくないですね。

module System.Text.Encoding
let UTF8 = ()

このようなモジュールを定義すると、System.Text.Encoding.UTF8の定義を上書きできます。 そして、System.Text.Encoding.UTF8を使おうとすると型が合わずコンパイルエラーになってしまいます。

コンパイルエラーがやり過ぎだと思ったら、ObsoleteAttributeを付けて警告にもできます。

module System.Text.Encoding
let [<System.Obsolete>]UTF8 = System.Text.Encoding.UTF8

この方法はUTF8プロパティのみ上書きされ、他のメンバは普段どおり使用できます。

使ってほしくないクラス、モジュールを制限する

次の例は、.NetにはXMLを扱うには2つの方法があります。 古くからあるSystem.Xml名前空間と、Linq to XmlのSystem.Xml.Linq名前空間の2つです。 System.Xml名前空間にあるクラスは使いづらいので、プロジェクト全体で使わせたくない上に、何も指示しないとSystem.Xmlのクラスを使う人までいます。

使わせたくない！コードレビューの時では遅いのだ！

先程は同名のモジュールを定義して、同名のメンバを定義しましたが、今度は同名のクラスを定義します。

namespace System.Xml
type XmlDocument private() = class end

もともとのSystem.Xml.XmlDocumentにアクセスしようと思っても、上記の定義が邪魔をして使えなくなってしまいます。

open System.Xml
let x = XmlDocument() (* この型にアクセスできるオブジェクト コンストラクターはありません *)

めでたしめでたし。

まとめ

こういうのはLintの仕事だと思いました。

モジュールのアクセシビリティ管理を手抜きする

F＃ には、モジュール内の要素（型、関数）のアクセシビリティを指定するには、2つの方法があります。

1. シグネチャファイルを使う
2. 非公開要素毎に internal / private を指定する

シグネチャファイルは、型名のみ公開しメンバは隠すなど、柔軟にアクセシビリティを指定できます。しかし、実装とシグネチャが別ファイル、同期が大変、という辛さがあり、手軽には使えません。

また、非公開要素毎に internal / private を指定する方法は、要素数が多くなれば指定に手間がかかる、ファイルを見ただけでは公開メンバの一覧が分からない問題があります。

シグネチャファイルを使うまでもなく、手軽にアクセシビリティを制御したい場合は、こう書くと良いんじゃないかなぁと思います。

module Hoge

(* 公開したい型はここに定義する *)

module internal Impl =
  (* 実装に必要な関数、型をImplモジュールに押し込む *)

  let f x = ()

let f x = Impl.f x (* 実際に公開したい関数 *)

実行時にCompiledNameが付いた型の元の名前を取得する

正確には実行時じゃないけど解決したのでメモ

元ネタ: http://ja.stackoverflow.com/questions/6177/compilednameが付いた型のf-での名前を取得したい

問題

F#では、CompiledNameAttributeを付けた型は、リフレクションで元の名前を取得できません。

[<CompiledName("Piyo")>]
type Hoge() = class end

というクラスを定義し、リフレクションで型名を取得しようとすると、

> typeof<Hoge>.Name;;
val it : string = "Piyo"

"Piyo"という文字列が返ります。

ソースコード上では"Hoge"という名前でしかアクセスできないのに、取得できないのは何かと不便ですね？

コンパイル前の名前が格納されている場所

アセンブリに、リソースとしてFSharpSignatureData.{AssemblyName}という名前で埋め込まれています。

typeof<Piyo>.Assembly.GetManifestResourceStream("FSharpSignatureData.Library1")

というコードで取得できます。

詳しいフォーマットは分かりませんが、取得できたバイナリを覗いてみると確かに"Hoge"という文字列が入っています。

FSharp.Compiler.Service を使うといい

これらのページを参考にすると、

http://fsharp.github.io/FSharp.Compiler.Service/ja/project.html https://github.com/fsharp/FSharp.Compiler.Service/issues/187

こんな感じのコードで取得できるみたいです。

module CompilerServiceStudy

[<CompiledName("Piyo")>]
type Hoge() = class end

open System.IO

let base1 = Path.GetTempFileName()
let fileName1 = Path.ChangeExtension(base1, ".fs")
let projFileName = Path.ChangeExtension(base1, ".fsproj")
let dllName = Path.ChangeExtension(base1, ".dll")

open Microsoft.FSharp.Compiler.SourceCodeServices

let asm = typeof<Hoge>.Assembly

let checker = FSharpChecker.Create()
let projectOptions =
  let sysLib name =
    System.Environment.GetFolderPath(System.Environment.SpecialFolder.ProgramFilesX86)
    + @"\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\"
    + (name + ".dll")
  let fsCore4300() =
    System.Environment.GetFolderPath(System.Environment.SpecialFolder.ProgramFilesX86)
    + @"\Reference Assemblies\Microsoft\FSharp\.NETFramework\v4.0\4.3.0.0\FSharp.Core.dll"  
  checker.GetProjectOptionsFromCommandLineArgs
    (projFileName,
      [| yield "--simpleresolution" 
         yield "--noframework" 
         yield "--debug:full" 
         yield "--define:DEBUG" 
         yield "--optimize-" 
         yield "--out:" + dllName
         yield "--warn:3" 
         yield "--fullpaths" 
         yield "--flaterrors" 
         yield "--target:library" 
         yield fileName1
         let references =
           [ sysLib "mscorlib" 
             sysLib "System"
             sysLib "System.Core"
             fsCore4300()
             asm.Location ]
         for r in references do 
               yield "-r:" + r |])
let wholeProjectResults = checker.ParseAndCheckProject(projectOptions) |> Async.RunSynchronously
let refAssemblies = wholeProjectResults.ProjectContext.GetReferencedAssemblies()

let thisAssembly = refAssemblies |> List.find (fun a -> a.SimpleName = asm.GetName().Name)
let thisModule = thisAssembly.Contents.Entities |> Seq.find (fun e -> e.DisplayName = "CompilerServiceStudy")
let piyoClass = thisModule.NestedEntities |> Seq.find (fun e -> e.CompiledName = "Piyo")
let hogeName = piyoClass.DisplayName

> CompilerServiceStudy.hogeName;;
val it : string = "Hoge"

無事"Hoge"が取得できました。ただし内部でコンパイルしているため、初めの1回はすごく遅いです。

F# Puzzle 2

問題

次のコードは何が出力されるでしょうか？

let toUpper (x: string) -> x.ToUpper()
if true then
  "hoge"
else
  "piyo"
|> toUpper

F# Puzzle

問題

次のコードで何が出力されるでしょうか？ 軽量構文を使ってます！

[
  for x in [ 1; 2; ] do
  for y in [ 10; 20; ] do
    yield x + y
  for z in [ 100; 200; ] do
    yield z
]

文字列比較の罠

突然のF# Advent Calendar 2014 - connpassの24日目です。

F# のdisりネタを紹介したいと思います！　こんなふざけた挙動のくせに調子乗らないで下さい！

文字列比較の挙動

F# の文字列比較には2種類の方法があります。演算子(<, <=, >, >=)を使う方法とCompareToメソッドを使う方法です。

"B" < "b"
"B".CompareTo("b") < 0

それぞれの結果がどうなるか分かりますか？

> "B" < "b";;
val it : bool = true
> "B".CompareTo("b") < 0;;
val it : bool = false

結果が違いますね！　ていうかこんな挙動誰も知らないよ！　同じだと思うだろ普通！！！　職場でも、@pocketberserker が嵌ってくれました。

C# ではどうなってんだよ？と思ったのですが、そもそも C# では演算子を使った文字列比較は出来ないんですよねー。

また、List.sortとEnumerable.OrderByの結果も違います。

> List.sort [ "a"; "b"; "A"; "B"; ];;
val it : string list = ["A"; "B"; "a"; "b"]
> [ "a"; "b"; "A"; "B"; ].OrderBy(fun x -> x);;
val it : IOrderedEnumerable<string> = seq ["a"; "A"; "b"; "B"]

そして、OCamlの実行結果です。

# "B" < "b";;
- : bool = true
# List.sort compare [ "a"; "b"; "A"; "B"; ];;
- : string list = ["A"; "B"; "a"; "b"]

どうやらOCamlの挙動と合わせたようです。確かにF#にはML互換のコンパイラオプションもありますが、そのオプションを使った時だけにして欲しかったなぁ……。

ListModuleを使ってEnumerable.OrderByと挙動を同じにしたい場合は、次のようにします。

> [ "a"; "b"; "A"; "B"; ] |> List.sortWith (fun x y -> x.CompareTo(y));;
val it : string list = ["a"; "A"; "b"; "B"]

ちなみに、こう書くと型推論に失敗しますが、これはまた別のdisりネタ。

List.sortWith (fun x y -> x.CompareTo(y)) [ "a"; "b"; "A"; "B"; ]

ドキュメント

この件のドキュメントは見つけられませんでした。誰か見つけたら教えてー。

実装

社内チャットで相談したところ、実装を見ようということになりました。俺が F# のリポジトリを clone している間に、@bleis がソースを読んで、@k_disposeがILを読んで、サクッと解決されてしまいました。「ILに追い付いてきた」とか競ってました。なんなんコイツら。

(<)演算子

"B" < "b"

で出力されるILをILSpyで見てみると、

LanguagePrimitives.HashCompare.GenericLessThanIntrinsic<string>("B", "b");

と表示されます。CompareToを呼んでいないぞ？　つぎはGenericLessThanIntrinsicの実装を見てみましょう。ファイルはprim-types.fs:1239辺りです。

let GenericLessThanIntrinsic (x:'T) (y:'T) = 
    try
        (# "clt" (GenericComparisonWithComparerIntrinsic fsComparer x y) 0 : bool #)
    with
        | e when System.Runtime.CompilerServices.RuntimeHelpers.Equals(e, NaNException) -> false

こんな感じにどんどん潜って行くと、次のコードに突き当たります。ファイルはprim-types.fs:957辺りです。

let rec GenericCompare (comp:GenericComparer) (xobj:obj,yobj:obj) = 
    (*if objEq xobj yobj then 0 else *)
      //System.Console.WriteLine("xobj = {0}, yobj = {1}, NaNs = {2}, PERMode.mode = {3}", [| xobj; yobj; box PER_NAN_PAIR_DETECTED; box PERMode.mode |])
      match xobj,yobj with 
       | null,null -> 0
       | null,_ -> -1
       | _,null -> 1
#if INVARIANT_CULTURE_STRING_COMPARISON
       // Use invariant culture comparison for strings
       | (:? string as x),(:? string as y) -> System.String.Compare(x, y, false, CultureInfo.InvariantCulture)
#else
       // Use Ordinal comparison for strings
       | (:? string as x),(:? string as y) -> System.String.CompareOrdinal(x, y)
#endif

なにやらINVARIANT_CULTURE_STRING_COMPARISONフラグでString.Compareを呼ぶかString.CompareOrdinalを呼ぶか分岐しています？

ここのILは、

internal static int GenericCompare(LanguagePrimitives.HashCompare.GenericComparer comp, object xobj, object yobj)
{
//...
        if (text != null)
        {
            string text2 = yobj as string;
            if (text2 != null)
            {
                string strB = text2;
                string strA = text;
                return string.CompareOrdinal(strA, strB);
            }

String.CompareOrdinalを呼んでいますね。つまり、FSharp.CoreはINVARIANT_CULTURE_STRING_COMPARISONを指定せずにビルドされているようです。

String.CompareOrdinalは、文字に対応するCharオブジェクトの数値を比較するメソッドです。 Bは0x42、bは0x62だから、"B" < "b"の結果がtrueになるんですね。

List.sort

List.sortの場合は、同じようにして、次のコードにたどり着きます。ファイルはprim-types.fs:1269辺りです。

let inline GenericComparisonFast<'T> (x:'T) (y:'T) : int = 
     GenericComparisonIntrinsic x y
     //...
     when 'T : string = 
#if INVARIANT_CULTURE_STRING_COMPARISON
         // NOTE: we don't have to null check here because System.String.Compare
         // gives reliable results on null values.
         System.String.Compare((# "" x : string #) ,(# "" y : string #), false, CultureInfo.InvariantCulture)
#else
         // NOTE: we don't have to null check here because System.String.CompareOrdinal
         // gives reliable results on null values.
         System.String.CompareOrdinal((# "" x : string #) ,(# "" y : string #))
#endif

ここでもINVARIANT_CULTURE_STRING_COMPARISONが出てきました。

まとめ

文字列は比較する方法により結果が変わるので、コードレビューで意図通りの比較になっているか確認する等して、対策しましょう。

文字列比較用の演算子を定義するのも考えられますが、次の理由でやめたほうがいいと思います。

• オリジナルの比較演算子(<, <=, >, >=)を使ってしまった時にコンパイルエラーにできない
• List.sortの挙動は変わらない

それでも俺はString.Compareを使って欲しいんだ！って人は、INVARIANT_CULTURE_STRING_COMPARISONを指定してFSharp.Coreをビルドすればいいみたいです。