O que há de especial no curry ou na aplicação parcial?

Eu tenho lido artigos sobre programação funcional todos os dias e tentado aplicar algumas práticas o máximo possível. Mas não entendo o que é único no curry ou na aplicação parcial.

Tome este código Groovy como um exemplo:

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

Eu não entendo qual é a diferença entre tripler1e tripler2. Eles não são os mesmos? O 'currying' é suportado em linguagens funcionais puras ou parciais, como Groovy, Scala, Haskell, etc. função ou fechamento que encaminhará os parâmetros para a função original (como tripler2) na maioria dos idiomas (até C.)

Estou faltando alguma coisa aqui? Há lugares em que posso usar curry e aplicação parcial no meu aplicativo Grails, mas hesito em fazê-lo porque estou me perguntando "Qual é a diferença?"

Por favor me esclareça.

EDIT: Vocês estão dizendo que aplicação parcial / currying é simplesmente mais eficiente do que criar / chamar outra função que encaminha parâmetros padrão para a função original?

Currying consiste em transformar / representar uma função que recebe n entradas em n funções em que cada uma recebe 1 entrada. Aplicação parcial é sobre como fixar algumas das entradas em uma função.

A motivação para a aplicação parcial é principalmente o fato de facilitar a gravação de bibliotecas de funções de ordem superior. Por exemplo, todos os algoritmos do C ++ STL usam predicados ou funções unárias, o bind1st permite que o usuário da biblioteca conecte funções não unárias com um valor vinculado. O escritor da biblioteca, portanto, não precisa fornecer funções sobrecarregadas para todos os algoritmos que executam funções unárias para fornecer versões binárias

O curry em si é útil porque oferece aplicação parcial em qualquer lugar que você desejar de graça, ou seja, você não precisa mais de uma função bind1stpara aplicar parcialmente.

Mas eu posso fazer a mesma coisa (aplicação com curry esquerdo, curry direito, n-curry ou parcial) simplesmente criando outra função ou fechamento nomeado ou anônimo que encaminhará os parâmetros para a função original (como tripler2) na maioria dos idiomas ( mesmo C.)

E o otimizador analisará isso e seguirá rapidamente para algo que possa entender. O curry é um pequeno truque para o usuário final, mas possui benefícios muito melhores do ponto de vista do design de linguagem. É muito bom lidar com todos os métodos como unários, A -> Bonde Bpode haver outro método.

Ele simplifica os métodos que você precisa escrever para lidar com funções de ordem superior. Sua análise estática e otimização no idioma têm apenas um caminho para trabalhar com esse comportamento de maneira conhecida. A ligação de parâmetros simplesmente cai fora do design, em vez de exigir a utilização de argolas para executar esse comportamento comum.

Como @jk. Como mencionado, o currying pode ajudar a tornar o código mais geral.

Por exemplo, suponha que você tenha essas três funções (em Haskell):

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

> let r g = g 3

> let f a b = b (a 1)

A função faqui assume duas funções como argumentos, passa 1para a primeira função e passa o resultado da primeira chamada para a segunda função.

Se chamássemos fusing qe rcomo argumentos, estaria efetivamente:

> r (q 1)

onde qseria aplicado 1e retornaria outra função (como qé exibida); essa função retornada seria então passada para rcomo argumento a ser dado um argumento de 3. O resultado disso seria um valor de 9.

Agora, digamos que tivemos duas outras funções:

> let s a = 3 * a

> let t a = 4 + a

também podemos passar esses valores fe obter um valor de 7or 15, dependendo de nossos argumentos serem s tor t s. Como essas funções retornam um valor em vez de uma função, nenhuma aplicação parcial ocorreria em f s tou f t s.

Se tivéssemos escrito fcom qe rem mente, poderíamos ter usado um lambda (função anônima) em vez de aplicação parcial, por exemplo:

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

mas isso teria restringido a generalidade de f'. fpode ser chamado com argumentos qe rou se t, mas f'só pode ser chamado com qe r- f' s te f' t sambos resultam em um erro.

MAIS

Se f'fosse chamado com um par q'/ r'em q'que o argumento tivesse mais de dois argumentos, q'ele ainda acabaria sendo parcialmente aplicado f'.

Como alternativa, você pode quebrar qfora ou fnão dentro, mas isso deixaria uma lambda aninhada desagradável:

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

que é essencialmente o que o caril qestava em primeiro lugar!

Existem dois pontos principais sobre a aplicação parcial. A primeira é sintática / conveniente - algumas definições se tornam mais fáceis e curtas de ler e escrever, como o @jk mencionou. (Confira a programação do Pointfree para saber mais sobre como isso é incrível!)

O segundo, como @telastyn mencionou, é sobre um modelo de funções e não é apenas conveniente. Na versão Haskell, da qual vou obter meus exemplos porque não estou familiarizado com outras linguagens com aplicação parcial, todas as funções usam um único argumento. Sim, até funções como:

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

pegue um único argumento; devido à associatividade do construtor do tipo de função ->, o acima é equivalente a:

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

que é uma função que recebe ae retorna uma função [a] -> [a].

Isso nos permite escrever funções como:

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

que pode aplicar qualquer função a um argumento do tipo apropriado. Mesmo os loucos, 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

Ok, então esse foi um exemplo artificial. Mas uma mais útil envolve a classe do tipo Aplicative , que inclui este método:

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

Como você pode ver, o tipo é idêntico $se você remover o Applicative fbit e, de fato, essa classe descreve a aplicação de funções em um contexto. Então, em vez da aplicação da função normal:

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

Podemos aplicar funções em um contexto Aplicativo; por exemplo, no contexto Talvez, em que algo pode estar presente ou ausente:

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

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

Agora, a parte mais interessante é que a classe do tipo Applicative não menciona nada sobre funções de mais de um argumento - no entanto, pode lidar com elas, inclusive funções de 6 argumentos como f:

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

Até onde eu sei, a classe do tipo Aplicativo em sua forma geral não seria possível sem alguma concepção de aplicação parcial. (Para qualquer especialista em programação existente - corrija-me se eu estiver errado!) É claro que, se sua linguagem não possui aplicação parcial, você pode construí-la de alguma forma, mas ... não é a mesma coisa, é? ? :)