9

Don Syme、Adam Granicz、および Antonio Cisternino によるExpert F# 2.0 では、 pg. 44

型推論: |> 演算子を使用すると、入力オブジェクトからそれらのオブジェクトを操作する関数に型情報が流れます。F# は、型の推論から収集された情報を使用して、プロパティ アクセスやメソッドのオーバーロードなどの一部の言語構造を解決します。これは、プログラムのテキストを介して左から右に伝達される情報に依存しています。特に、プロパティ アクセスとオーバーロードを解決するときに、位置の右側にある型情報は考慮されません。

したがって、明らかに |> を使用すると、型の推論に役立ちます。

いつものように、型を宣言することも役に立ちます。

F# 型の推論を支援するために使用できる他の手段/戦術はありますか?

編集

RamonSnir が正しく指摘したように、型推論に可能な限り多くの作業を行わせることになっています。したがって、できるという理由だけで型宣言を追加することは、すべきことではありません。この質問や回答を、やるべきことだと思わないでください。型推論のニュアンスと、型推論に助けが必要な場合に何が役立つかをよりよく理解するために、この質問をしました。したがって、型推論が助けなしですべての型を解決できる場合は、何も与えないでください。

4

1 に答える 1

14

いくつかのポイント:

1) プロパティやメソッドよりもモジュール関数を優先します。

List.map (fun x -> x.Length) ["hello"; "world"] // fails
List.map String.length ["hello"; "world"] // works

let mapFirst xss = Array.map (fun xs -> xs.[0]) xss // fails
let mapFirst xss = Array.map (fun xs -> Array.get xs 0) xss // works

2) オーバーロードのないメソッドを優先します。たとえば、QuickLinq ヘルパーは、オーバーロードされていないメンバーを定義して、LINQ 拡張メソッドでの一連の型注釈を回避します。

3) 利用可能な情報を利用して、型チェッカーにヒントを与えます。

let makeStreamReader x = new System.IO.StreamReader(x) // fails
let makeStreamReader x = new System.IO.StreamReader(path=x) // works

最後の例は、 F# の型推論に関する優れた記事から抜粋したものです。

結論として、多くの場合、F# 型チェッカーを支援する必要はありません。型エラーがある場合は、上記のリンクの要約が適切な修正ガイドラインを提供します。

要約すると、コンパイラが型の欠落や十分な情報がないと文句を言っている場合にできることは次のとおりです。

  • 使用する前に物事を定義します (これには、ファイルが正しい順序でコンパイルされていることを確認することが含まれます)
  • 「既知の型」を持つものを「未知の型」を持つものよりも前に置きます。特に、型付けされたオブジェクトが最初になるように、パイプや同様の連鎖関数を並べ替えることができる場合があります。
  • 必要に応じて注釈を付けます。一般的なトリックの 1 つは、すべてが機能するまで注釈を追加し、必要最小限になるまで 1 つずつ削除することです。可能であれば、注釈を付けないようにしてください。見た目が良くないだけでなく、コードがもろくなります。明示的な依存関係がない場合、型を変更するのははるかに簡単です。
于 2012-12-11T14:44:07.800 に答える