Ordenamiento de parámetros para hacer uso del curry


93

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?

Respuestas:


111

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.

Como corolario del primer punto, coloque también el argumento que puede vivir en una estructura de datos al final. Hace que el mapa, el pliegue y los amigos estén más limpios. tl; dr lo de la lista va al último.
John F. Miller

1
La búsqueda no se puede encadenar de todos modos, por lo que el primer punto no lo respalda. haskell.org/haskellwiki/Parameter_order hace un argumento convincente al revés: "Dado que los objetos de tipo Map representan asignaciones, es natural tener alguna función que transforme un objeto Map en la función representada".
Brandon

11

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.


5
Si de hecho está mapeando muchas funciones sobre la misma lista, tal vez debería hacer una lista de funciones y map ($myList)sobre esa lista en su lugar.
Calamardo

3

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).

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.