Re: [boost] painless currying

Subject: Re: [boost] painless currying
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-08-24 16:38:17

on Wed Aug 24 2011, Eric Niebler <eric-AT-boostpro.com> wrote:

> On 8/24/2011 12:55 PM, Dave Abrahams wrote:
>> 
>> on Wed Aug 24 2011, Eric Niebler <eric-AT-boostpro.com> wrote:
>> 
>>> On 8/24/2011 4:28 AM, Thomas Heller wrote:
>>>>
>>>> However, the problem comes with function objects having operator() overloads 
>>>> with different arity. Another problem I couldn't solve yet is how to decide 
>>>> which overload gets curryied or not.
>>>> Consider:
>>>>
>>>> struct foo
>>>> {
>>>>    void operator()(int);
>>>>    void operator()(int, int);
>>>> };
>>>>
>>>> curryable<foo> f;
>>>> auto curried = f(1); // To curry or not to curry, that is the question
>>>
>>> As soon as enough arguments are collected to call the curried function,
>>> it gets called. So in this case, f(1) calls f::operator()(int).
>> 
>> That's an asymmetry about most currying syntax that I never liked, at
>> least for C++.  
>
> Could you explain what you mean by asymmetry here? That my currying code
> prefers one function over another based on the available arguments?

I mean this, for a ternary function f:

  f(x) => doesn't call f
  f(x)(y) => doesn't call f
  f(x)(y)(z) => calls f

That last step looks asymmetric to me.

In a lazy language, f(x)(y)(z) *doesn't* call f... until you actually
use the result for something... which is more consistent-looking.

I suppose the symmetrical non-lazy version looks like:

  f(x) => doesn't call f
  f(x)(y) => doesn't call f
  f(x)(y)(z) => doesn't call f
  f(x)(y)(z)() => calls f

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com