design - recursive - modules haskell
Pedido de parámetros para hacer uso del currying (3)
He cambiado el código de dos veces recientemente para cambiar el orden de los parámetros porque había demasiados códigos en los que se producían hacks como flip o /x -> foo bar x 42 .
Al diseñar una función, ¿qué principios me ayudarán a aprovechar al máximo el currículum?
Coloque los argumentos que es más probable que reutilice primero. Los argumentos de función son un gran ejemplo de esto. Es mucho más probable que desee map f sobre dos listas diferentes, que desea mapear muchas funciones diferentes sobre la misma lista.
Para lenguajes que soportan currying y parcial-application fácilmente, hay una serie convincente de argumentos, originalmente de Chris Okasaki:
- Coloque la estructura de datos como el último argumento
¿Por qué? A continuación, puede componer las operaciones en los datos muy bien. Por ejemplo, insert 1 $ insert 2 $ insert 3 $ s . Esto también ayuda a las funciones de estado .
Las bibliotecas estándar como "contenedores" siguen esta convención .
A veces se dan argumentos alternativos para poner la estructura de datos primero, de modo 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 amplio consenso parece ser que esto no es tan exitoso, especialmente porque lo empuja hacia un código entre paréntesis.
- Pon el último argumento variando
Para las funciones recursivas, es común poner el argumento que más varía (por ejemplo, un acumulador) como último argumento, mientras que el argumento que menos varía (por ejemplo, un argumento de función) al comienzo. Esto se combina bien con la estructura de datos del último estilo.
Se proporciona un resumen de la vista de Okasaki en su biblioteca de Edison (una vez más, otra biblioteca de estructura de datos):
- Aplicación parcial : los argumentos que suelen ser estáticos suelen aparecer antes que otros argumentos para facilitar la aplicación parcial.
- La colección aparece al final : en todos los casos donde una operación consulta una sola colección o modifica una colección existente, el argumento de colección aparecerá en último lugar. Esto es algo así como un estándar de facto para las bibliotecas de estructuras de datos de Haskell y otorga un grado de consistencia a la API.
- Orden más usual : cuando una operación representa una función matemática bien conocida en más de una estructura de datos, los argumentos se eligen para que coincidan con el orden de argumento más habitual para la función.
Tiendo a hacer lo que hizo, elegir un orden que parece bueno y luego refactorizar si resulta que otro orden es mejor. El orden depende mucho de cómo vas a usar la función (naturalmente).