カレーを利用するためのパラメータの順序付け

私は二回、最近のようなハックあまりにも多くのコードがあったので、パラメータの順序を変更するために、コードをリファクタリングしているflipかが\x -> foo bar x 42起こったが。

関数シグネチャを設計するとき、カレーを最大限に活用するのに役立つ原則は何ですか？

カレー化と部分適用を簡単にサポートする言語については、Chris Okasakiがもともと提供している説得力のある一連の議論があります。

• データ構造を最後の引数として置く

どうして？その後、データに対する操作を適切に構成できます。例えばinsert 1 $ insert 2 $ insert 3 $ s。これは、状態の関数にも役立ちます。

「コンテナ」などの標準ライブラリは、この規則に従います。

代替の引数がデータ構造を最初に置くために与えられることがあるので、それを閉じることができ、静的な構造（たとえばルックアップ）で関数が少し簡潔になります。ただし、広い括弧で囲まれているため、括弧でくくられたコードに向かっているので、これはあまりうまくいきません。

• 最も多様な議論を最後に置く

再帰関数の場合、最も変化する引数（アキュムレータなど）を最後の引数として配置するのが一般的ですが、変化が最も少ない引数（関数引数など）を最初に配置します。これは、データ構造の最後のスタイルでうまく構成されています。

岡崎ビューの要約は、彼のEdisonライブラリー（ここでも、別のデータ構造ライブラリー）に記載されています。

• 部分的な適用：通常、静的である可能性が高い引数は、部分的な適用を容易にするために、他の引数の前に表示されます。
• コレクションは最後に表示されます。操作が単一のコレクションをクエリしたり、既存のコレクションを変更したりする場合はすべて、コレクション引数が最後に表示されます。これはHaskellデータ構造ライブラリの事実上の標準の1つであり、APIにある程度の一貫性をもたらします。
• 最も通常の順序：演算が複数のデータ構造で既知の数学関数を表す場合、引数は、関数の最も通常の引数の順序と一致するように選択されます。

最初に再利用する可能性が最も高い引数を配置します。関数の引数はこの良い例です。あなたは、はるかにしたいと思われるmap fあなたは同じリストの上に多くの異なる機能をマップするためにあるよりも、2種類以上のリスト。

私はあなたがしたことをする傾向があり、良いと思われるいくつかの注文を選び、次に別の注文がより良いことが判明した場合はリファクタリングします。順序は、関数を（自然に）使用する方法に大きく依存します。