Re: [boost] painless currying

Subject: Re: [boost] painless currying
From: Eric Niebler (eric_at_[hidden])
Date: 2011-08-26 13:31:28

On 8/26/2011 1:10 PM, Dave Abrahams wrote:
> 
> on Thu Aug 25 2011, Eric Niebler <eric-AT-boostpro.com> wrote:
> 
>> On 8/25/2011 4:16 PM, Dave Abrahams wrote:
>>> on Thu Aug 25 2011, Eric Niebler <eric-AT-boostpro.com> wrote:
>>>> I simply don't see the problem with:
>>>>
>>>> f(x) ==> curry
>>>> f(x, y) or f(x)(y) ==> curry
>>>> f(x, y, z) or etc. ==> evaluate
>>>>
>>>> Can you say specifically what you think the problem is? 
>>>
>>> It just rubs me the wrong way that sometimes passing arguments to a
>>> function has no execution semantics, but if you happen to complete an
>>> argument list, suddenly it's called.
>>
>> OK. You say tomahto.
> 
> Let's call the whole thing eagerly!
> 
>>>> This is how its done in Haskell, for instance (although Haskell
>>>> doesn't use parens around argument lists).
>>>
>>> Well, no, it's not exactly how it's done in Haskell, because in Haskell
>>> f is lazy, and that's what makes the difference.
>>
>> Yes, I know. I don't consider that difference particularly relevant to
>> this discussion, though. If (f x y x) type-checks as Int you pass it as
>> an argument to a function that takes an Int, it type-checks. If you pass
>> (f x y) as an argument to a function that takes a
>> unary-function-that-returns-Int, it type-checks.
> 
> Yeah... but in C++ we generally distinguish nullary functions from their
> results, and we generally care when things are invoked.

That's true. But nobody wants to curry a nullary function, so I guess
you're arguing by extension that we should likewise be concerned about
potential confusion when more arguments are involved. And I still don't
see what is confusing about it. Can you give an example where plausible
code gives surprising results because of implicit currying instead of
explicit binding?

>>>>> Yes, it has always been my view that bind was unambiguously better
>>>>> for non-lazy languages, and at least more flexible even for lazy
>>>>> ones.
>>>>
>>>> Better and more flexible in what ways?
>>>
>>> It's better because it avoids confusion about when things are invoked.
>>
>> Meh.
> 
> That's an argument?

About as convincing an argument as "it rubs me the wrong way." ;-)

>>> It's more flexible because it allows the 2nd argument to be bound before
>>> the first argument is available.
>>
>> You snipped the part of my message where I said that that problem is
>> easily solvable, and now you're pretending I never said it. :-/
> 
> Please, can't we at least make a show of assuming we're discussing this
> with general goodwill?  I didn't notice you saying it was easily
> solvable, nor did I notice a proposed solution, so I'm not pretending.
> If you said it, great.  How do you solve it?

Sorry, I regretted that as soon as I clicked send. Damn fingers. Here's
the bit you snipped:

Eric Niebler wrote:
> I don't see any technical obstacles to:
> 
> f(_, y, z)
> 
> where _ is a placeholder. You could use positional placeholders for
> argument reordering.

You might say the syntactic advantages of this over bind(f, _, y, z) are
minimal. You might be right.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com