オーバーロードが解決されるルール?

どうもこんばんは。G'Camlの路上販売を試みたものの巨大資本の前に敗れ去り、港*1で海を眺めているYTです。

型レの発表内容について、id:camlspotterさんに補足いただきました。ありがたや。
Obj.magic(またはassert false)を使わないで済む構造など、非常に参考になります。

で、型レでlimitationsとして、次のようなis_same_typeの各引数に同じ型を与えた場合、int -> intは'b -> 'cにもマッチするためオーバーロードが解決されずtrue_tが得られないみたいな話をしたのでした。

val is_same_type: [| 'a -> 'a -> true_t | 'b -> 'c -> false_t |]

それに対して、このような反論?がなされてます。

さて、型が同じかどうか判定できないのではないかという話があったけれども、これは、マァ出来る、という主張をしておきたい
(中略)
これは GCaml の変態的 overload resolution priority のおかげ。Overload resolution しなくちゃいけないけど、複数のケースがマッチするときは、先に宣言された方を勝手に GCaml が選んでくれる。正直キモいが、便利な時もある。とういう訳で、型が同じかどうか、というか、 unifiable かどうかは、GCaml では expansive let による auto overload resolution を使えば可能、ということです:

確かに上が優先というのはk.inabaさんの資料の内容とも一致します。
しかし現実にis_same_typeはオーバーロードが解決されない。例示されたTComp.compareと、is_same_typeの何が違うのかイマイチわからなかったので、色々実験してみました。

*1:G'CamlのMacPorts用野良Portfile書きましたのでよろしければご利用ください。

続きを読む