¿Qué tiene de especial el curry o la aplicación parcial?

He estado leyendo artículos sobre programación funcional todos los días y he tratado de aplicar algunas prácticas tanto como sea posible. Pero no entiendo qué es único en el curry o la aplicación parcial.

Tome este código Groovy como ejemplo:

def mul = { a, b -> a * b }
def tripler1 = mul.curry(3)
def tripler2 = { mul(3, it) }

No entiendo cuál es la diferencia entre tripler1y tripler2. ¿No son los dos iguales? El 'curry' es compatible con lenguajes funcionales puros o parciales como Groovy, Scala, Haskell, etc. Pero puedo hacer lo mismo (left-curry, right-curry, n-curry o aplicación parcial) simplemente creando otro nombre o anónimo función o cierre que reenviará los parámetros a la función original (como tripler2) en la mayoría de los idiomas (incluso C.)

¿Me estoy perdiendo de algo? Hay lugares donde puedo usar el currículum y la aplicación parcial en mi solicitud de Grails, pero dudo en hacerlo porque me pregunto "¿Cómo es eso diferente?"

Por favor iluminame.

EDITAR: ¿Están diciendo que la aplicación / currículum parcial es simplemente más eficiente que crear / llamar a otra función que reenvía los parámetros predeterminados a la función original?

El curry se trata de convertir / representar una función que toma n entradas en n funciones que cada una toma 1 entrada. La aplicación parcial se trata de arreglar algunas de las entradas a una función.

La motivación para la aplicación parcial es principalmente que facilita la escritura de bibliotecas de funciones de orden superior. Por ejemplo, los algoritmos en C ++ STL toman en gran medida predicados o funciones unarias, bind1st permite al usuario de la biblioteca enganchar funciones no unarias con un valor enlazado. Por lo tanto, el escritor de la biblioteca no necesita proporcionar funciones sobrecargadas para todos los algoritmos que toman funciones unarias para proporcionar versiones binarias

El curring en sí mismo es útil porque le brinda una aplicación parcial en cualquier lugar que desee de forma gratuita, es decir, ya no necesita una función como bind1staplicar parcialmente.

Pero puedo hacer lo mismo (curry izquierdo, curry derecho, n-curry o aplicación parcial) simplemente creando otra función o cierre con nombre o anónimo que reenvíe los parámetros a la función original (como tripler2) en la mayoría de los idiomas ( incluso C.)

Y el optimizador lo verá y pasará rápidamente a algo que pueda entender. El curry es un pequeño y agradable truco para el usuario final, pero tiene beneficios mucho mejores desde el punto de vista del diseño del lenguaje. Es realmente agradable manejar todos los métodos como unarios, A -> Bdonde Bpuede haber otro método.

Simplifica qué métodos tiene que escribir para manejar funciones de orden superior. Su análisis estático y optimización en el idioma solo tiene una ruta para trabajar que se comporta de manera conocida. La unión de parámetros simplemente se cae del diseño en lugar de requerir que los aros hagan este comportamiento común.

Como @jk. Aludido, curry puede ayudar a hacer el código más general.

Por ejemplo, suponga que tiene estas tres funciones (en Haskell):

> let q a b = (2 + a) * b

> let r g = g 3

> let f a b = b (a 1)

La función faquí toma dos funciones como argumentos, pasa 1a la primera función y pasa el resultado de la primera llamada a la segunda función.

Si tuviéramos que llamar fusando qy rcomo argumentos, efectivamente estaría haciendo:

> r (q 1)

donde qse aplicaría 1y devolvería otra función (como qse curry); esta función devuelta se pasaría a rsu argumento para que se le dé un argumento de 3. El resultado de esto sería un valor de 9.

Ahora, digamos que teníamos otras dos funciones:

> let s a = 3 * a

> let t a = 4 + a

podríamos pasar esto ftambién y obtener un valor de 7o 15, dependiendo de si nuestros argumentos eran s to t s. Dado que estas funciones devuelven un valor en lugar de una función, no se llevaría a cabo una aplicación parcial en f s to f t s.

Si hubiéramos escrito fcon qy ren mente, podríamos haber usado una lambda (función anónima) en lugar de una aplicación parcial, por ejemplo:

> let f' a b = b (\x -> a 1 x)

pero esto habría restringido la generalidad de f'. fse puede llamar con argumentos qy ro sy t, pero f'solo se puede llamar con qy r, f' s ty f' t sambos producen un error.

MÁS

Si f'se llamara con un q'/ r'par donde q'tomaron más de dos argumentos, el q'todavía terminaría siendo aplicado parcialmente f'.

Alternativamente, podría envolver qafuera en flugar de adentro, pero eso lo dejaría con una desagradable lambda anidada:

f (\x -> (\y -> q x y)) r

que es esencialmente lo que el curry qera en primer lugar!

Hay dos puntos clave sobre la aplicación parcial. El primero es sintáctico / conveniente: algunas definiciones se vuelven más fáciles y cortas de leer y escribir, como mencionó @jk. (¡Mira la programación de Pointfree para obtener más información sobre lo increíble que es esto!)

El segundo, como mencionó @telastyn, trata sobre un modelo de funciones y no es simplemente conveniente. En la versión de Haskell, de la que obtendré mis ejemplos porque no estoy familiarizado con otros lenguajes con aplicación parcial, todas las funciones toman un solo argumento. Sí, incluso funciona como:

(:) :: a -> [a] -> [a]

tomar un solo argumento; Debido a la asociatividad del constructor del tipo de función ->, lo anterior es equivalente a:

(:) :: a -> ([a] -> [a])

que es una función que toma ay devuelve una función [a] -> [a].

Esto nos permite escribir funciones como:

($) :: (a -> b) -> a -> b

que puede aplicar cualquier función a un argumento del tipo apropiado. Incluso los locos como:

f :: (t, t1) -> t -> t1 -> (t2 -> t3 -> (t, t1)) -> t2 -> t3 -> [(t, t1)]
f q r s t u v = q : (r, s) : [t u v]

f' :: () -> Char -> (t2 -> t3 -> ((), Char)) -> t2 -> t3 -> [((), Char)]
f' = f $ ((), 'a')  -- <== works fine

Bien, ese fue un ejemplo artificial. Pero una más útil involucra la clase de tipo Aplicativo , que incluye este método:

(<*>) :: Applicative f => f (a -> b) -> f a -> f b

Como puede ver, el tipo es idéntico al de $quitar el Applicative fbit y, de hecho, esta clase describe la aplicación de funciones en un contexto. Entonces, en lugar de la aplicación de función normal:

ghci> map (+3) [1..5]  
[4,5,6,7,8]

Podemos aplicar funciones en un contexto Aplicativo; por ejemplo, en el contexto Quizás en el que algo puede estar presente o faltante:

ghci> Just map <*> Just (+3) <*> Just [1..5]
Just [4,5,6,7,8]

ghci> Just map <*> Nothing <*> Just [1..5]
Nothing

Ahora la parte realmente genial es que la clase de tipo Aplicativo no menciona nada sobre funciones de más de un argumento; sin embargo, puede tratar con ellas, incluso funciones de 6 argumentos como f:

fA' :: Maybe (() -> Char -> (t2 -> t3 -> ((), Char)) -> t2 -> t3 -> [((), Char)])
fA' = Just f <*> Just ((), 'a')

Hasta donde sé, la clase de tipo Aplicativo en su forma general no sería posible sin alguna concepción de aplicación parcial. (Para cualquier experto en programación, ¡corríjame si me equivoco!) Por supuesto, si su idioma no tiene una aplicación parcial, podría construirlo de alguna forma, pero ... simplemente no es lo mismo, ¿verdad? ? :)