Re: [boost] painless currying

Subject: Re: [boost] painless currying
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-08-25 08:59:34

On Thursday, August 25, 2011 11:16:21 AM Daniel James wrote:
> On 25 August 2011 10:33, Mathias Gaunard <mathias.gaunard_at_[hidden]> 
wrote:
> > On 25/08/2011 01:18, Daniel James wrote:
> >> On 24 August 2011 23:11, Mathias Gaunard<mathias.gaunard_at_[hidden]>
> >> 
> >>  wrote:
> >>> On 08/24/2011 06:55 PM, Dave Abrahams wrote:
> >>>> That's an asymmetry about most currying syntax that I never liked,
> >>>> at
> >>>> least for C++.  I suppose when all functions are fully lazy
> >>>> there's no
> >>>> assymmetry, but that's not C++.  In C++ we have parens to trigger
> >>>> evaluation.  Even in Phoenix, laziness only goes partway: you
> >>>> still need parens to trigger final evaluation.
> >>> 
> >>> ML-based languages are not lazy and have had currying for 40 years.
> >>> Yet the academics behind functional programming, lambda calculus,
> >>> theorem proving and logic still seem to fancy them a lot.
> >> 
> >> But ML doesn't have C++ style overloading. Currying certain overloaded
> >> functions is ambiguous.
> > 
> > Which is why I suggested only applying currying to monomorphic
> > functions.
> 
> But that's not much good for C++. Explicitly specifying the number of
> arguments is a bit better, but then the situations where that can do
> something that bind can't are quite rare.
> 
> I think explicit partial function calls would be a better fit for C++, i.e.
> 
> std::transform(begin(), end, inserter,
>     partial(std::plus<int>(), 10));
> 
> It would be clear when you're explicitly calling the function, and
> when you're not. And the implementation would be considerably simpler.
> It could support placeholders if you don't like simplicity.

So, what is the difference to bind? Or the old bind1st bind2nd?
Or just _1 + 10, or 10 + _1?

The more I think of it the more confident I am that the current bind 
implementations are the best for the general case.
 
> I think an 'uncurry' is also possible, I'm not sure how useful it would be.