Ordenamiento de parámetros para hacer uso del curry

Recientemente, he refactorizado dos veces el código para cambiar el orden de los parámetros porque había demasiado código donde me gustaban flipo \x -> foo bar x 42estaban ocurriendo hackeos .

Al diseñar una firma de función, ¿qué principios me ayudarán a hacer el mejor uso del curado?

Para los lenguajes que admiten currying y aplicaciones parciales fácilmente, hay una serie de argumentos convincentes, originalmente de Chris Okasaki:

• Pon la estructura de datos como último argumento

¿Por qué? A continuación, puede componer operaciones sobre los datos sin problemas . Ej insert 1 $ insert 2 $ insert 3 $ s. Esto también ayuda para funciones en estado .

Las bibliotecas estándar como "contenedores" siguen esta convención .

A veces se dan argumentos alternativos para poner la estructura de datos en primer lugar, por lo que se puede cerrar, produciendo funciones en una estructura estática (por ejemplo, búsqueda) que son un poco más concisas. Sin embargo, el consenso general parece ser que esto es menos beneficioso, especialmente porque lo empuja hacia un código muy entre paréntesis.

• Ponga el argumento más variado al final

Para funciones recursivas, es común colocar el argumento que más varía (por ejemplo, un acumulador) como último argumento, mientras que el argumento que varía menos (por ejemplo, un argumento de función) al principio. Esto se compone bien con el último estilo de estructura de datos.

Se ofrece un resumen de la vista de Okasaki en su biblioteca de Edison (nuevamente, otra biblioteca de estructura de datos):

• Aplicación parcial : los argumentos con mayor probabilidad de ser estáticos suelen aparecer antes que otros argumentos para facilitar la aplicación parcial.
• La colección aparece en último lugar : en todos los casos en los que una operación consulta una única colección o modifica una colección existente, el argumento de la colección aparecerá en último lugar. Esto es algo así como un estándar de facto para las bibliotecas de estructura de datos de Haskell y le da un grado de consistencia a la API.
• Orden más habitual : cuando una operación representa una función matemática conocida en más de una estructura de datos, los argumentos se eligen para que coincidan con el orden de argumentos más habitual para la función.

Coloque primero los argumentos que es más probable que reutilice. Los argumentos de función son un gran ejemplo de esto. Es mucho más probable que desee tener map fmás de dos listas diferentes que mapear muchas funciones diferentes en la misma lista.

Tiendo a hacer lo que tú hiciste, elegir un pedido que parece bueno y luego refactorizar si resulta que otro pedido es mejor. El orden depende mucho de cómo vas a usar la función (naturalmente).