On Thursday, August 25, 2011 11:16:21 AM Daniel James wrote:
On 25 August 2011 10:33, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 25/08/2011 01:18, Daniel James wrote:
On 24 August 2011 23:11, Mathias Gaunard<mathias.gaunard@ens-lyon.org>
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.