Modismos de composición de función de Haskell (.) Y aplicación de función ($): uso correcto

He estado leyendo Real World Haskell , y me estoy acercando al final, pero una cuestión de estilo me ha estado fastidiando con los operadores (.)y ($).

Cuando escribe una función que es una composición de otras funciones, la escribe así:

f = g . h

Pero cuando aplicas algo al final de esas funciones, lo escribo así:

k = a $ b $ c $ value

Pero el libro lo escribiría así:

k = a . b . c $ value

Ahora, para mí se ven funcionalmente equivalentes, hacen exactamente lo mismo en mis ojos. Sin embargo, cuanto más miro, más veo a las personas que escriben sus funciones de la manera en que lo hace el libro: componer (.)primero y luego solo al final usar ($)para agregar un valor para evaluar el lote (nadie lo hace con muchas composiciones en dólares) .

¿Hay alguna razón para usar los libros que sea mucho mejor que usar todos los ($)símbolos? ¿O hay alguna mejor práctica aquí que no estoy obteniendo? ¿O es superfluo y no debería preocuparme en absoluto?

Creo que puedo responder esto desde la autoridad.

¿Hay alguna razón para usar la forma de los libros que sea mucho mejor que usar todos los símbolos ($)?

No hay una razón especial. Bryan y yo preferimos reducir el ruido de la línea. .es más silencioso que $. Como resultado, el libro usa la f . g . h $ xsintaxis.

De hecho, son equivalentes: tenga en cuenta que el $operador no hace, esencialmente, nada. f $ xevalúa a f x. El propósito de $es su comportamiento de fijación: derecho-asociativo y precedencia mínima. Al eliminar $y usar paréntesis para agrupar en lugar de precedencia infija, los fragmentos de código se ven así:

k = a (b (c (value)))

y

k = (a . b . c) value

La razón para preferir la .versión sobre la $versión es la misma razón para preferir ambas sobre la versión entre paréntesis anterior: atractivo estético.

Sin embargo, algunos podrían preguntarse si el uso de operadores de infijo en lugar de paréntesis se basa en una necesidad subconsciente de evitar cualquier posible parecido con Lisp (es broma ... ¿creo?).

Agregaría eso f . g $ x, f . ges una unidad sintáctica significativa.

Mientras tanto, en f $ g $ x, f $ gno es una unidad significativa. Una cadena de $es posiblemente más imperativa: primero obtenga el resultado gde x, luego hágalo f, luego hágalo foo, luego etc.

Mientras tanto, una cadena de .es posiblemente más declarativa y, en cierto sentido, más cercana a una vista centrada en el flujo de datos: componga una serie de funciones y, en última instancia, las aplique a algo.

Para mí, creo que la respuesta es (a) la pulcritud, como dijo Don ; y (b) encuentro que cuando estoy editando código, mi función puede terminar en un estilo libre de puntos, y luego todo lo que tengo que hacer es eliminar el último en $lugar de regresar y cambiar todo. Un punto menor, sin duda, pero agradable.

Hay una discusión interesante de esta pregunta en este hilo de Haskell-Cafe . Aparentemente, hay un punto de vista minoritario que sostiene que la asociatividad correcta $es "simplemente errónea" , y elegir f . g . h $ xsobre f $ g $ h $ xes una forma de esquivar el problema.

Es solo una cuestión de estilo. Sin embargo, la forma en que lo hace el libro tiene más sentido para mí. Compone todas las funciones y luego lo aplica al valor.

Su método se ve extraño, y el último $es innecesario.

Sin embargo, realmente no importa. En Haskell, generalmente hay muchas, muchas formas correctas de hacer lo mismo.

Me doy cuenta de que esta es una pregunta muy antigua, pero creo que hay otra razón para esto que no se ha mencionado.

Si está declarando una nueva función sin puntos f . g . h, el valor que pase se aplicará automáticamente. Sin embargo, si escribe f $ g $ h, no funcionará.

Creo que la razón por la que el autor prefiere el método de composición es porque lleva a una buena práctica de desarrollar funciones.