[Issue 8142] std.functional.curry isn't flexible enough
https://issues.dlang.org/show_bug.cgi?id=8142 Iain Buclaw changed: What|Removed |Added Priority|P2 |P4 --
[Issue 8142] New: std.functional.curry isn't flexible enough
http://d.puremagic.com/issues/show_bug.cgi?id=8142 Summary: std.functional.curry isn't flexible enough Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2012-05-24 14:40:11 PDT --- std.functional.curry doesn't work if the first argument (the curried one) is a function. This is a common enough use case: import std.functional; auto foo(T)(T function(T x) f, T x) { return f(x); } int bar(int x) { return x * 2; } alias curry!(foo, bar) fooBar; void main() {} DMD 2.060alpha gives: temp.d(6): Error: expression bar is not a valid template value argument temp.d(6): Error: template instance std.functional.curry!(foo, bar) error instantiating I think D functional-style programming needs a more flexible/uniform currying. Workaround: import std.traits: ParameterTypeTuple; auto foo(alias F)(ParameterTypeTuple!F[0] x) { return F(x); } int bar(int x) { return x * 2; } alias foo!bar fooBar; void main() { assert(fooBar(5) == 10); } But this is not as flexible. A language that supports functional programming needs to handle functions as first class citizens. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Re: std.functional.curry isn't
On Thu, 24 Jun 2010 20:19:47 -0500, Andrei Alexandrescu wrote: On 06/24/2010 07:06 PM, Graham Fawcett wrote: Hi folks, The template std.functional.curry(alias fun, alias arg) claims to curry fun by tying its first argument to a particular value. That is not currying; it is partial application. [...] Confusing curring and partial application is a very common mistake. But please rename this template in std.functional. It makes the std.functional module look amateurish to have such an error. Hm, fine. The whole curry thing was an experiment that I put on hold because back then I couldn't support functions with any number of arguments, which puts a damp on enthusiasm. I suggest you to send a patch to bugzilla in case you have the time. Andrei Thank you. http://d.puremagic.com/issues/show_bug.cgi?id=4391 Best, Graham
Re: std.functional.curry isn't
On 06/25/2010 08:39 AM, Graham Fawcett wrote: On Thu, 24 Jun 2010 20:19:47 -0500, Andrei Alexandrescu wrote: On 06/24/2010 07:06 PM, Graham Fawcett wrote: Hi folks, The template std.functional.curry(alias fun, alias arg) claims to curry fun by tying its first argument to a particular value. That is not currying; it is partial application. [...] Confusing curring and partial application is a very common mistake. But please rename this template in std.functional. It makes the std.functional module look amateurish to have such an error. Hm, fine. The whole curry thing was an experiment that I put on hold because back then I couldn't support functions with any number of arguments, which puts a damp on enthusiasm. I suggest you to send a patch to bugzilla in case you have the time. Andrei Thank you. http://d.puremagic.com/issues/show_bug.cgi?id=4391 Great. I'm hoping for a patch that fixes the problem, but it's good to have the report we don't forget this. Andrei
Re: std.functional.curry isn't
On Fri, Jun 25, 2010 at 16:36, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 06/25/2010 08:39 AM, Graham Fawcett wrote: Thank you. http://d.puremagic.com/issues/show_bug.cgi?id=4391 Great. I'm hoping for a patch that fixes the problem, but it's good to have the report we don't forget this. I'm using this, without problem up to now, it works for n-args functions (even 0 or 1) and accepts template functions too, but see the doc for the limitation in this case. /** 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. I posted it as a comment in the bug report, in case it can help someone write something. Philippe
std.functional.curry isn't
Hi folks, The template std.functional.curry(alias fun, alias arg) claims to curry fun by tying its first argument to a particular value. That is not currying; it is partial application. In particular, it is a kind of partial application called a left section, because the argument provided is partially applied as the left-hand argument of the binary function. Partial application takes a binary function and a value, and returns a unary function. Currying takes a binary function and returns a unary function, which returns a unary function. Let [A,B]- C be the type of binary functions taking arguments of types A and B, and returning a value of type C. A unary function from B to C can be written [B]-C. left section: [ ([A,B]-C), A ] - ([B] - C). right section: [ ([A,B]-C), B ] - ([A] - C). curry: [ ([A,B]-C) ] - ([A] - ([B] - C)). The example in the std.functional documentation: int fun(int a, int b) { return a + b; } alias curry!(fun, 5) fun5; assert(fun5(6) == 11); If this were a real curry, you would write it like this: int fun(int a, int b) { return a + b; } assert(curry!(fun)(5)(6) == 11); Confusing curring and partial application is a very common mistake. But please rename this template in std.functional. It makes the std.functional module look amateurish to have such an error. I'd vote for template partial(alias fun, alias arg) and template partialR(alias fun, alias arg) for left and right sections. It's unlikely that you really need a curry template at all. Regards, Graham
Re: std.functional.curry isn't
On Thu, Jun 24, 2010 at 5:06 PM, Graham Fawcett fawc...@uwindsor.ca wrote: Hi folks, The template std.functional.curry(alias fun, alias arg) claims to curry fun by tying its first argument to a particular value. That is not currying; it is partial application. In particular, it is a kind of partial application called a left section, because the argument provided is partially applied as the left-hand argument of the binary function. Partial application takes a binary function and a value, and returns a unary function. Currying takes a binary function and returns a unary function, which returns a unary function. Let [A,B]- C be the type of binary functions taking arguments of types A and B, and returning a value of type C. A unary function from B to C can be written [B]-C. left section: [ ([A,B]-C), A ] - ([B] - C). right section: [ ([A,B]-C), B ] - ([A] - C). curry: [ ([A,B]-C) ] - ([A] - ([B] - C)). The example in the std.functional documentation: int fun(int a, int b) { return a + b; } alias curry!(fun, 5) fun5; assert(fun5(6) == 11); If this were a real curry, you would write it like this: int fun(int a, int b) { return a + b; } assert(curry!(fun)(5)(6) == 11); Confusing curring and partial application is a very common mistake. But please rename this template in std.functional. It makes the std.functional module look amateurish to have such an error. I'd vote for template partial(alias fun, alias arg) and template partialR(alias fun, alias arg) for left and right sections. It's unlikely that you really need a curry template at all. Regards, Graham Agreed. I brought up the same thing back when curry() was just an example in the documentation of variadic templates. --bb
Re: std.functional.curry isn't
Graham Fawcett: If this were a real curry, you would write it like this: int fun(int a, int b) { return a + b; } assert(curry!(fun)(5)(6) == 11); Right. Better to change the name. Regarding std.functional, are the HOF adjoin(), compose() and pipe() useful? I don't think I'll use compose() or pipe(). If not enough people find them useful, then they can be removed. There is something that instead I'd like added (that I am going to put as request in Bugzilla, maybe later today): Apply functionality is quite useful, as shown by this small Python program that prints 1, 2: def foo(x, y): print x, y tuple1 = (1, 2) foo(*tuple1) That star syntax of Python is equivalent to this, that works still in Python 2.x: apply(foo, tuple1) The star syntax can't be used in D, but a good apply() function can be useful in D too. There the tuple is of course a std.typecons.Tuple. Bye, bearophile
Re: std.functional.curry isn't
On 06/24/2010 07:06 PM, Graham Fawcett wrote: Hi folks, The template std.functional.curry(alias fun, alias arg) claims to curry fun by tying its first argument to a particular value. That is not currying; it is partial application. [...] Confusing curring and partial application is a very common mistake. But please rename this template in std.functional. It makes the std.functional module look amateurish to have such an error. Hm, fine. The whole curry thing was an experiment that I put on hold because back then I couldn't support functions with any number of arguments, which puts a damp on enthusiasm. I suggest you to send a patch to bugzilla in case you have the time. Andrei
Re: std.functional.curry isn't
On 06/24/2010 07:37 PM, bearophile wrote: Graham Fawcett: If this were a real curry, you would write it like this: int fun(int a, int b) { return a + b; } assert(curry!(fun)(5)(6) == 11); Right. Better to change the name. I think it would be even better to redefine curry to do actual currying. Regarding std.functional, are the HOF adjoin(), compose() and pipe() useful? I don't think I'll use compose() or pipe(). If not enough people find them useful, then they can be removed. I'm finding them quite useful, particularly in conjunction with e.g. map. Andrei
Re: std.functional.curry isn't
Andrei Alexandrescu: I think it would be even better to redefine curry to do actual currying. Right. I'm finding them quite useful, particularly in conjunction with e.g. map. Oh, OK. Then let's keep them :-) What do you think about the apply? Bye, bearophile