Чи називає groovy часткове застосування «каррінг»?

У Groovy існує концепція, яку він називає «каррінг». Ось приклад з їхньої вікі:

def divide = { a, b -> a / b }

def halver = divide.rcurry(2)

assert halver(8) == 4

Я розумію, що відбувається тут, полягає в тому, що правий аргумент divideприв’язується до значення 2. Це здається формою часткового застосування.

Термін currying зазвичай використовується для означання перетворення функції, яка бере ряд аргументів у функцію, яка бере лише один аргумент і повертає іншу функцію. Наприклад, ось тип curryфункції в Haskell:

curry :: ((a, b) -> c) -> (a -> (b -> c))

Для людей, які не використовували Haskell a, bі cвсі загальні параметри. curryприймає функцію з двома аргументами і повертає функцію, яка приймає aта повертає функцію з bдо c. Я додав додаткову пару дужок до типу, щоб зробити це більш зрозумілим.

Чи я неправильно зрозумів, що відбувається в грубому прикладі, або це просто неправильне часткове застосування? Або насправді це робить і те, і інше: тобто перетворити divideна функцію curried, а потім частково застосувати 2до цієї нової функції.

Реалізація Groovy curryнасправді не викликає куріння, навіть за кулісами. Він по суті ідентичний частковому застосуванню.

В curry, rcurryі ncurryметоди повертають CurriedClosureоб'єкт , який утримує пов'язані аргументи. Він також має метод getUncurriedArguments(неправильно названий - ви curry функції, а не аргументи), який повертає композицію переданих йому аргументів зв'язаними аргументами.

Коли укупорочное викликається, в кінцевому підсумку це викликає в invokeMethodметодMetaClassImpl , який явно перевіряє , щоб побачити , якщо викликає об'єкт є екземпляром CurriedClosure. Якщо це так, він використовує вищезгадане, getUncurriedArgumentsщоб скласти повний масив аргументів для застосування:

if (objectClass == CurriedClosure.class) {
    // ...
    final Object[] curriedArguments = cc.getUncurriedArguments(arguments);
    // [Ed: Yes, you read that right, curried = uncurried. :) ]
    // ...
    return ownerMetaClass.invokeMethod(owner, methodName, curriedArguments);
}

Виходячи із заплутаної та дещо непослідовної номенклатури вище, я підозрюю, що кожен, хто це написав, має хороше концептуальне розуміння, але, можливо, трохи поспішав і - як багато розумних людей - плутав каррі з частковим застосуванням. Це зрозуміло (див. Відповідь Пола Кінга), якщо трохи прикро; це буде важко виправити, не порушуючи зворотної сумісності.

Я запропонував одне рішення - перевантажити curryметод таким чином, що коли аргументи не передаються, він робить справжній currying, і знецінює виклик методу аргументами на користь нової partialфункції. Це може здатися трохи дивним , але це дозволило б максимально збільшити зворотну сумісність - оскільки немає причин використовувати часткове застосування з нульовими аргументами - уникаючи при цьому (IMHO) потворнішої ситуації мати нову, інакше названу функцію для правильного currying, а функція насправді названий curryробить щось інше і заплутано подібне.

Само собою зрозуміло, що результат виклику curryабсолютно відрізняється від фактичного висипу. Якби це справді викривило функцію, ви зможете написати:

def add = { x, y -> x + y }
def addCurried = add.curry()   // should work like { x -> { y -> x + y } }
def add1 = addCurried(1)       // should work like { y -> 1 + y }
assert add1(1) == 2 

… І це спрацювало б, бо addCurriedтреба працювати так { x -> { y -> x + y } }. Натомість це кидає виняток із виконання, і ти трохи помреш всередині.

Я думаю, що зрозуміло, що насичений каррі - це фактично часткове застосування при розгляді функцій з більш ніж двома аргументами. розглянути

f :: (a,b,c) -> d

його викривлена ​​форма була б

fcurried :: a -> b -> c -> d

проте curry groovy поверне щось еквівалентне (припускаючи, що викликається з 1 аргументом x)

fgroovy :: (b,c) -> d 

який буде викликати f зі значенням фіксованого на x

тобто, хоча curry groryy може повертати функції з аргументами N-1, curry функції належним чином мають лише один аргумент, тому groovy не може бути curry з curry

Groovy запозичив найменування своїх методів каррі з численних інших нечистих мов FP, які також використовують подібні імена для часткового застосування - можливо, прикро для такої FP-орієнтованої функціональності. Існує декілька "справжніх" реалізацій каррі, що пропонуються для включення в Groovy. Хороша нитка, щоб почати читати про них, ось тут:

http://groovy.markmail.org/thread/c4ycxdzm3ack6xxb

Існуюча функціональність залишатиметься в певній формі, а сумісність назад буде врахована під час виклику щодо того, як назвати нові методи і т. Д. - тому на цьому етапі я не можу сказати, яким буде остаточне називання нових / старих методів бути. Можливо, компроміс щодо називання, але ми побачимо.

Для більшості програмістів OO відмінність між двома термінами (каррінг та часткове застосування), мабуть, значною мірою є академічним; однак, як тільки ви звикли до них (і хто буде підтримувати ваш код, навчений читати цей стиль кодування), тоді безпроблемне або мовчазне програмування стилю (яке "справжня" підтримка currying) дозволяє певні види алгоритмів виражатись більш компактно а в деяких випадках більш елегантно. Очевидно, тут є якась "краса в очах глядача", але можливість підтримувати обидва стилі відповідає природі Гроові (OO / FP, статична / динамічна, класи / сценарії тощо).

Враховуючи це визначення, знайдене в IBM:

Термін каррі взято від Haskell Curry, математика, який розробив концепцію часткових функцій. Currying - це прийняття декількох аргументів у функцію, яка бере багато аргументів, в результаті чого виникає нова функція, яка бере аргументи, що залишилися, і повертає результат.

halver- це ваша нова (зрізана) функція (або закриття), яка тепер бере лише один параметр. Виклик halver(10)призведе до 5.

Для цього вона перетворює функцію з n аргументів у функцію з n-1 аргументами. Те саме говорить ваш приклад haskell, що робить каррі.