groovy

Real currying support

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: 3.0
  • Component/s: groovy-jdk
  • Labels:
    None
  • Number of attachments :
    0

Description

Hi.

Groovy's Closure have a name of method 'curry'.
But this is not work for a real currying, it work as a partial function application.
So, I wrote method of 'Real currying'.

Referenced http://en.wikipedia.org/wiki/Currying

Closure add = {a, b, c -> a + b + c } // Closure of adding 3 arguments.

assert add(1, 2, 3) == realCurry(add)(1)(2)(3)
assert 6 == add(1, 2, 3)
def curriedAdd = realCurry(add)
def curriedAdd_1 = curriedAdd(1)
def curriedAdd_1_2 = curriedAdd_1(2)
def addResult = curriedAdd_1_2(3)
assert 6 == addResult

def realCurry(Closure clos) {
  if (clos.maximumNumberOfParameters >= 1) {
    return { x ->
      def cc = clos.curry(x)
      if (cc.maximumNumberOfParameters) realCurry(cc)
      else cc()
    }
  } else {
    return clos
  }
}

(It's also published on gist https://gist.github.com/1193548)

I hope this will be adopted to Groovy core.

Thank you.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
blackdrag blackdrag added a comment -

the point you are referring to is realCurry(add)(1)(2)(3), instead of our add.curry(1).curry(2).curry(3). Furthermore add.curry(1) results in an add, in which the first argument will be 1 and only second and third can be applied any more, while realCurry(add) returns a function that takes only one argument and returns then a new function, in which add will have 1 set as first argument, but again accepts only one argument. Applying the final argument gives the result then.

Yoshida, do you have some examples in which you can show the advantage of real currying over partial function application?

Show
blackdrag blackdrag added a comment - the point you are referring to is realCurry(add)(1)(2)(3), instead of our add.curry(1).curry(2).curry(3). Furthermore add.curry(1) results in an add, in which the first argument will be 1 and only second and third can be applied any more, while realCurry(add) returns a function that takes only one argument and returns then a new function, in which add will have 1 set as first argument, but again accepts only one argument. Applying the final argument gives the result then. Yoshida, do you have some examples in which you can show the advantage of real currying over partial function application?
Hide
Permalink
Kentaro Yoshida added a comment -

Hi, Jochen Theodorou.

Beginning of what is I thought that the name of curry evokes not partial function application but real currying.
So, I wrote realCurry code.

But, well on second thought, For Groovy, 'realCurry' is perhaps not necessary because it can partial function application by a curry method on Closure, even if function is not fully curried like Haskell.

If possible, please adding that curry method works as partial function application on API documentation?

Thank you.

Show
Kentaro Yoshida added a comment - Hi, Jochen Theodorou. Beginning of what is I thought that the name of curry evokes not partial function application but real currying. So, I wrote realCurry code. But, well on second thought, For Groovy, 'realCurry' is perhaps not necessary because it can partial function application by a curry method on Closure, even if function is not fully curried like Haskell. If possible, please adding that curry method works as partial function application on API documentation? Thank you.
Hide
Permalink
Russel Winder added a comment -

Jochen,

I think the point here is that this is another case of the Groovy label being a mish-mash of concepts as understood in the wider world. The Groovy curry function is not performing a curry, hence Kentaro Yoshida's point. Can I suggest that this is marked "not a bug" for Groovy 1, but in Groovy 2 this is sorted out (along with what a closure is) so that Groovy aligns with the commonly accepted meanings of these jargon words?

{ a , b , c -> a + b + c }.curry ( ) == { a -> { b -> { c -> a + b + c } } }
Show
Russel Winder added a comment - Jochen, I think the point here is that this is another case of the Groovy label being a mish-mash of concepts as understood in the wider world. The Groovy curry function is not performing a curry, hence Kentaro Yoshida's point. Can I suggest that this is marked "not a bug" for Groovy 1, but in Groovy 2 this is sorted out (along with what a closure is) so that Groovy aligns with the commonly accepted meanings of these jargon words? { a , b , c -> a + b + c }.curry ( ) == { a -> { b -> { c -> a + b + c } } }
Hide
Permalink
blackdrag blackdrag added a comment -

sure we can do, thought I cannot guarantee it will be taken over like this. Also what name should our curry then have?

Show
blackdrag blackdrag added a comment - sure we can do, thought I cannot guarantee it will be taken over like this. Also what name should our curry then have?
Hide
Permalink
Russel Winder added a comment -

The function currently called curry is really partial application so partial. However might it be possible to have a sophisticated call mechanism so that:

{ a , b , c -> a + b + c } ( 2 ) == { a , b -> 2 + a + b }

clearly I am taking some liberties with the equality operator here

Show
Russel Winder added a comment - The function currently called curry is really partial application so partial. However might it be possible to have a sophisticated call mechanism so that: { a , b , c -> a + b + c } ( 2 ) == { a , b -> 2 + a + b } clearly I am taking some liberties with the equality operator here
Hide
Permalink
blackdrag blackdrag added a comment -

I would prefer not to do that directly on Closure, because I want the error message sometimes. But it is possible

Show
blackdrag blackdrag added a comment - I would prefer not to do that directly on Closure, because I want the error message sometimes. But it is possible

People

  • Assignee:
    Unassigned
    Reporter:
    Kentaro Yoshida
Vote (1)
Watch (2)

Dates

  • Created:
    Updated: