Use case for std.bind

[Jason House]

Andrei Alexandrescu Wrote:

> 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. 


Sorry about that. I'm sleep deprived and working extra long hours at work lately.


> 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.

The first follow-up to your reply captured the kind of messiness bind can bring in C++. So far, all your examples are trivial (lack argument reordering, function composition, etc...). It's true that your examples look clean, but the devil will be in the details.

I'd give better examples/details if I wasn't typing this with my thumb into a cell phone... I'm normally a man of few words, but that makes me give less detail than I otherwise would.
 
> Andrei