Use case for std.bind

[Andrei Alexandrescu]

Jason House wrote:
> Andrei Alexandrescu Wrote:
>> int plus(int x, int y} { return x + y; } auto plus5 =
>> curry!(plus)(5); assert(plus5(10) == 15);
>> 
>> typeof(plus5) will be a little struct that may be cumbersome to
>> pass around, in which case you do want to take the toll of the
>> indirect call by writing:
>> 
>> auto plus5 = makeDelegate(curry!(plus)(5)); assert(is(typeof(plus5)
>> == int delegate(int)); assert(plus5(10) == 15);
>> 
>> This stuff belongs to std.functional. I plan to eliminate std.bind
>> and put currying and binding in std.functional. What do people
>> think?
>> 
>> Andrei
> 
> I've done the whole boost::bind thing before and it sucks. When
> boost::lambda came out, that was way better. Anonymous delegates are
> even better. Learning a separate functional syntax will always be a
> sub par solution to me.

So let's see. If what you have is a function int fun(int, int) and you 
want to fix its first parameter to a specific value, you can write:

(int x) { return fun(42, x); }

That would be a function literal. To give it a name, you can say:

int gun(int x) { return fun(42, x); }

If you want to pass that thing around, you take &gun (or &(literal)) and 
transform it into a delegate. One minor issue with the above is that the 
syntax is rather verbose and that the relationship between the function, 
the parameter, and the outcome is not conceptualized. Yes, the 
constructs can curry any function, but you have no *notion* of currying 
a function. So I thought of defining such a simple notion that would 
allow you to write:

curry!(fun)(42)

instead of the literals above. In your code you are of course free to 
use either form as you find fit, just as you can write x * x * x or 
cube(x) or pow(x, 3). So I'm not sure where the sub par thing comes.

> I'll go even further. If D had only what you've proposed for ranges
> and std.functional but lacked opApply and anonymous delegates, I
> never would have become a D user. Simple, clean syntax is that
> important to me...  Please don't recreate boost and STL in D.
> They're great libraries, but we can do way better than that!

This is the Usenet equivalent of a pie in the face. Wait, what? I 
_thought_ I'm far beyond recreating boost and STL and also that in the 
process I am using the full power of the language (and sometimes even 
more, as shown by the stream of bug reports and enhancement requests 
that I had to post recently). All range, functional, and algorithms do 
hinge on anonymous delegates (function literals in fact, which are 
considerably better); they don't compete with them at all, so I fail to 
see how one could be thought of in separation from the other. Anyhow, if 
you have some ideas on how we can do way better than the current trend 
I'm all ears. My perception, if you allow me to venture a thought, is 
that you are a bit confused. To paraphrase SICP, you are happy with x * 
x * x and are afraid that the option of writing cube(x) makes things worse.


Andrei