Boost logo

Boost :

Subject: Re: [boost] painless currying
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-08-26 13:10:17


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.

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

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

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk