Commande de paramètres pour utiliser le curry

Question

J'ai récemment refactorisé le code pour modifier l'ordre des paramètres car il y avait trop de code où des hacks comme flip ou \x -> foo bar x 42 se passaient.

Lors de la conception d'une signature de fonction, quels principes m'aideront à faire le meilleur usage du curry?

Answer 1

Pour les langues qui soutiennent le curry et la application partielle facilement, il y a une série de plaidoiries convaincantes, originaire de Chris Okasaki:

• Mettez la structure de données comme dernier argument

Pourquoi? Tu peux alors Composez les opérations sur les données bien. Par exemple insert 1 $ insert 2 $ insert 3 $ s. Cela aide également pour Fonctions à l'état.

Bibliothèques standard telles que "conteneurs" Suivez cette convention.

Des arguments alternatifs sont parfois donnés pour mettre la structure de données en premier, de sorte qu'ils peuvent être fermés, donnant des fonctions sur une structure statique (par exemple) qui sont un peu plus concises. Cependant, le large consensus semble être que c'est moins une victoire, d'autant plus qu'il vous pousse vers un code fortement entre parenthèse.

• Mettez l'argument le plus variable en dernier

Pour les fonctions récursives, il est courant de mettre l'argument qui varie le plus (par exemple un accumulateur) comme dernier argument, tandis que l'argument qui varie le moins (par exemple un argument de fonction) au début. Cela se compose bien avec la structure de données Last Style.

---

Un résumé de la vue d'Okasaki est donné dans Sa bibliothèque Edison (Encore une fois, une autre bibliothèque de structure de données):

• Application partielle: Les arguments plus susceptibles d'être statiques apparaissent généralement devant d'autres arguments afin de faciliter une application partielle.
• La collection apparaît en dernier: Dans tous les cas où une opération interroge une seule collection ou modifie une collection existante, l'argument de la collection apparaîtra en dernier. Il s'agit d'une norme de facto pour les bibliothèques de données Haskell et donne un certain degré de cohérence à l'API.
• L'ordre le plus habituel: Lorsqu'une opération représente une fonction mathématique bien connue sur plus d'une datastructure, les arguments sont choisis pour correspondre à l'ordre d'argument le plus habituel pour la fonction.

Answer 2

Placez les arguments que vous êtes le plus susceptible de réutiliser en premier. Les arguments de fonction en sont un excellent exemple. Vous êtes beaucoup plus susceptible de vouloir map f Sur deux listes différentes, que vous souhaitez cartographier de nombreuses fonctions différentes sur la même liste.

Answer 3

J'ai tendance à faire ce que vous avez fait, à choisir une commande qui semble bonne puis à refactor s'il s'avère qu'une autre commande est meilleure. La commande dépend beaucoup de la façon dont vous allez utiliser la fonction (naturellement).