Ordinamento dei parametri per utilizzare il curry

Di recente ho refactoring due volte del codice per modificare l'ordine dei parametri perché c'era troppo codice in cui gli hack come flipo \x -> foo bar x 42stavano accadendo.

Quando progetto una firma di funzione, quali principi mi aiuteranno a utilizzare al meglio il curry?

Per le lingue che supportano facilmente il currying e l'applicazione parziale, esiste una serie di argomenti convincenti, originariamente di Chris Okasaki:

• Metti la struttura dei dati come ultimo argomento

Perché? È quindi possibile comporre bene le operazioni sui dati . Ad esempio insert 1 $ insert 2 $ insert 3 $ s. Questo aiuta anche per le funzioni sullo stato .

Le librerie standard come i "contenitori" seguono questa convenzione .

A volte vengono forniti argomenti alternativi per mettere prima la struttura dei dati, in modo che possa essere chiusa, producendo funzioni su una struttura statica (ad esempio la ricerca) che sono un po 'più concise. Tuttavia, l'ampio consenso sembra essere che questa sia meno una vittoria, soprattutto perché ti spinge verso un codice fortemente tra parentesi.

• Metti per ultimo l'argomento più vario

Per le funzioni ricorsive, è comune mettere l'argomento che varia di più (ad esempio un accumulatore) come ultimo argomento, mentre l'argomento che varia di meno (ad esempio un argomento di funzione) all'inizio. Questo si sposa bene con l'ultimo stile della struttura dati.

Un riepilogo della vista di Okasaki è fornito nella sua libreria Edison (di nuovo, un'altra libreria di strutture dati):

• Applicazione parziale : gli argomenti con più probabilità di essere statici di solito compaiono prima di altri argomenti per facilitare l'applicazione parziale.
• La raccolta appare per ultima : in tutti i casi in cui un'operazione interroga una singola raccolta o modifica una raccolta esistente, l'argomento della raccolta apparirà per ultimo. Questo è una sorta di standard de facto per le librerie di strutture dati Haskell e conferisce un certo grado di coerenza all'API.
• Ordine più consueto : dove un'operazione rappresenta una funzione matematica ben nota su più di una struttura dati, gli argomenti vengono scelti in modo da corrispondere all'ordine degli argomenti più usuale per la funzione.

Inserisci per primi gli argomenti che probabilmente riutilizzerai. Gli argomenti delle funzioni ne sono un ottimo esempio. È molto più probabile che tu voglia map foltre due elenchi diversi, piuttosto che voler mappare molte funzioni diverse sullo stesso elenco.

Tendo a fare quello che hai fatto tu, scelgo un ordine che sembra buono e poi refactoring se si scopre che un altro ordine è migliore. L'ordine dipende molto da come userete la funzione (naturalmente).