MIYAZAKI Shohei

## ダブルクォートで囲まれた数値の扱い/推論の競合の検出 たしかに推論を汎用的にしようとすると、複雑ですがファジー関数の導入が必要なのかなぁと思います。 ユーザーが作った`TypeDefinition`にも対応できますし。 ``` type t = A of int | B of decimal ``` という型を定義した場合に、`1`という入力はどちらに推論されるのか？とかも、ファジー関数の導入で楽に調整できそうな気がします。 また、ファジー関数の結果が同じものが複数あれば、競合が検出できるってことですね。 `AcceptCons` の `Cons`とは何ですか？ なるべく略語は止めたいです。 ## 一部のUnionCaseを省略した場合の扱い そのケースは競合としてエラーにすれば良いと思います。

`TypeDefinition`の互換性を考慮するならインターフェイスでしょうか？ そのインターフェイスを実装していなかったら固定値を使うような。

ごめんなさい適当言いました。インターフェイスのことは忘れて下さい。

すみません考えが変わりました。 `TypeDefinition`型にファジー関数を公開したとして、互換性が崩れる上に、ユーザが正しく実装（FsYamlのソースを読んでいい感じに0~1の間の値を返す）できるとは思えないので、FsYaml内で閉じて実装したほうが良いでしょう。 ファジー関数が対応している型は、FsYamlがTypeDefinitions.fsに定義してデフォルトで提供している型で十分ではないでしょうか。もともとの課題にあった例でも、数値か文字列なのかしか挙げていません。また、この問題が起こるのは数値や文字列のプリミティブな型だと思います。 そうすると、ユーザが定義したTypeDefinitions.fsに定義されていない型は、優先度を一番低く（結果が1になる？）なりますね。

良いと思います。

一度書いたコメントの内容変えないでもらえますか？時間が無駄になりました。

`float`は`float`として扱う必要がある？