Ordre des paramètres pour utiliser le curry

J'ai récemment refacturé du code deux fois afin de changer l'ordre des paramètres car il y avait trop de code où les hacks aiment flipou \x -> foo bar x 42se produisaient.

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

Pour les langages qui prennent facilement en charge le curry et l'application partielle, il existe une série d'arguments convaincants, à l'origine de Chris Okasaki:

• Mettez la structure de données comme dernier argument

Pourquoi? Vous pouvez alors bien composer des opérations sur les données . Par exemple insert 1 $ insert 2 $ insert 3 $ s. Cela aide également pour les fonctions sur l'état .

Les bibliothèques standard telles que les «conteneurs» suivent cette convention .

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

• Mettez en dernier l'argument le plus varié

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 correspond bien au dernier style de la structure de données.

Un résumé de la vue 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 avant les 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 collection apparaîtra en dernier. Il s'agit d'un standard de facto pour les bibliothèques de structures de données Haskell et confère un certain degré de cohérence à l'API.
• Ordre le plus courant : lorsqu'une opération représente une fonction mathématique bien connue sur plus d'une structure de données, les arguments sont choisis pour correspondre à l'ordre des arguments le plus courant pour la fonction.

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 fsur deux listes différentes que de vouloir mapper de nombreuses fonctions différentes sur la même liste.

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