Bug 4391 – std.functional.curry is not a real curry
Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
phobos
Product
D
Version
D2
Platform
Other
OS
All
Creation time
2010-06-25T06:37:50Z
Last change time
2020-01-02T01:44:37Z
Keywords
bootcamp, pull
Assigned to
No Owner
Creator
Graham Fawcett
Comments
Comment #0 by graham.fawcett — 2010-06-25T06:37:50Z
The "curry" template in std.functional is not actually a curry, but a partial application.
A curry function should take a single argument, a binary function:
(A a, B b) { return ... }
and return a nested unary function:
(A a) { return (B b) { return ... }; };
Comment #1 by philippe.sigaud — 2010-06-25T12:13:39Z
(In reply to comment #0)
Here is a possible patch:
/**
Takes a D function, and curries it (in traditional, mathematical sense): given
a n-args function, it creates n 1-arg functions nested inside one another. When
all original arguments are reached, it returns the result.
Example:
----
int add(int i, int j) { return i+j;}
alias curry!add cadd; // cadd waits for an int, will return an int delegate(int)
auto add3 = cadd(3); // add3 is a function that take an int and return this int + 3.
auto m = map!add3([0,1,2,3]);
assert(equal(m, [3,4,5,6]));
bool equals(int i, int j) { return i==j;}
alias curry!equals cequals;
auto equals4 = cequals(4); // equals4 is a function taking an int and return true iff this int is 4.
auto f = filter!equals4([2,3,4,5,4,3,2,2,3,4]);
assert(equal(f, [4,4,4]));
----
What's fun is that it'll work for template functions too.
Example:
----
string conj(A, B)(A a, B b)
{
return to!string(a)~to!string(b);
}
alias curry!conj cconj;
auto c1 = cconj(1); // c1 is a template function waiting for any type.
assert(c1('a') == "1a");
----
BUG:
for now, it does not verify the compatibility of types while you give it the arguments. It's only
at the end that it sees whether or not it can call the function with these arguments.
Example:
----
// given a function like this, with dependencies between the arguments' types:
A foo(A,B,C)(A a, Tuple!(B,A) b, Tuple!(C,B,A) c) { return a+b.field[1]+c.field[2];}
// if you curries it and gives it an int as first argument, the returned template function should really be:
int foo2(B,C)(Tuple!(B,int) b) { return anotherFunction;}
// because we now know A to be an int...
----
*/
template curry(alias fun)
{
static if (isFunction!fun)
enum curry = mixin(curryImpl!(fun, "", ParameterTypeTuple!fun));
else
enum curry = curriedFunction!(fun)();
}
template curryImpl(alias fun, string xs, T...)
{
static if (T.length == 0)
enum curryImpl = "&fun";
else static if (T.length == 1)
enum curryImpl = "(" ~ T[0].stringof ~ " x1) { return fun(" ~ xs ~ "x1);}";
else
enum curryImpl = "(" ~ T[0].stringof ~ " x" ~ to!string(T.length) ~ ") { return "
~ curryImpl!(fun,xs ~ "x" ~ to!string(T.length) ~ ", ", T[1..$]) ~ ";}";
}
struct CurriedFunction(alias fun, T...) /+if (T.length)+/
{
T _t;
static if (T.length)
void initialize(T t) { _t = t;}
template OpCallType(U...)
{
static if (is (typeof(fun(Init!T, Init!U))))
alias typeof(fun(Init!T, Init!U)) OpCallType;
else
alias CurriedFunction!(fun, T, U) OpCallType;
}
OpCallType!U opCall(U...)(U u)
{
static if(is(typeof(fun(_t, u))))
return fun(_t,u);
else
{
CurriedFunction!(fun, T, U) cf;
static if (U.length) cf.initialize(_t, u);
return cf;
}
}
}
CurriedFunction!(fun, TypeTuple!()) curriedFunction(alias fun)()
{
CurriedFunction!(fun, TypeTuple!()) cf;
return cf;
}
unittest
{
int add(int i, int j) { return i+j;}
alias curry!add cadd; // cadd waits for an int, will return an int delegate(int)
auto add3 = cadd(3); // add3 is a function that take an int and return this int + 3.
auto m = map!add3([0,1,2,3]);
assert(equal(m, [3,4,5,6]));
bool equals(int i, int j) { return i==j;}
alias curry!equals cequals;
auto equals4 = cequals(4); // equals4 is a function taking an int and return true iff this int is 4.
auto f = filter!equals4([2,3,4,5,4,3,2,2,3,4]);
assert(equal(f, [4,4,4]));
}
So, the template function part is still a bit rough. I've plan to keep track of types dependencies, but ... well, Real Life (tm) is in the way.
Comment #2 by timon.gehr — 2011-06-09T11:16:23Z
I suggest to also keep the current implementation of "curry", but to rename it to "partial".
Comment #3 by code — 2011-09-03T17:53:09Z
@Timon: Agreed, having a »curry« that really performs partial application is quite confusing (and gets us into trouble if we want to add a real curry), this has been on my todo list for quite some time now.
Comment #4 by github-bugzilla — 2014-03-09T22:32:16Z
There has been some discussion about this in the NG:
http://forum.dlang.org/post/[email protected]
but unfortunately AFAICT curry still hasn't made its way into Phobos.
What happened to the patch Philippe posted?
@Andrei: The status says that this is assigned to you. I will set the status to "unassigned", please change you have this on your roadmap.
Comment #6 by andrei — 2017-02-22T21:42:46Z
Put this up for bootcamp.
Comment #7 by dlang-bot — 2019-04-16T22:57:43Z
@benjones updated dlang/phobos pull request #6963 "bugzilla issue 4391 add curry to std.functional " fixing this issue:
- Fix Issue 4391 - add curry to std.functional
https://github.com/dlang/phobos/pull/6963
Comment #8 by dlang-bot — 2020-01-02T01:44:37Z
dlang/phobos pull request #6963 "bugzilla issue 4391 add curry to std.functional " was merged into master:
- 866c0779d1d67c7863abea8974355d3e5eac0650 by Ben Jones:
Fix Issue 4391 - add curry to std.functional
https://github.com/dlang/phobos/pull/6963