# Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-08 21:24:05

David Abrahams <dave_at_[hidden]> writes:

>> There are problems with the approach of just using operator(). The
>> most convincing one, IMO, is that right now you can do
>>
>> int print_and_inc( int x ) {
>> cout << x << endl;
>> return x+1;
>> }
>> // now imagine "p_a_i" is the corresponding functoid
>>
>> // here is a nullary functoid which prints 3 and returns 4 when
>> // invoked:
>> lambda()[ p_a_i[3] ]
>>
>> If you eliminate operator[] and overload operator() to take on both
>> semantics, you can no longer easily "delay side effects" using lambda:
>>
>> // Whoops, prints now, rather than later when someone invokes it.
>> lambda()[ p_a_i(3) ]
>
> I wasn't suggesting eliminating []. Of course, Boost.Lambda uses
> constant(3) to achieve the same thing, but I like the terseness of [].
> The real problem is, you give up a lot of readability by having to
> write %plus% instead of +.

After some more thought, I have a question: what's the meaning of:

// f(x) -> 2*(x+3)
lambda(X)[
let[
Y == X %plus% 3 // y = x+3
, Fun == multiplies(2) // fun(x) -> 2*x NOTE PARENS
].in[
Fun[Y] // fun(y)
]
]

??

if it's the same as

// f(x) -> 2*(x+3)
lambda(X)[
let[
Y == X %plus% 3 // y = x+3
, Fun == multiplies[2] // fun(x) -> 2*x NOTE BRACKETS
].in[
Fun[Y] // fun(y)
]
]

Then I'm inclined to think
parens-on-lambda-variables-delays-evaluation is a reasonable idea.

```--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
```