
Boost : 
From: David Abrahams (dave_at_[hidden])
Date: 20031008 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
parensonlambdavariablesdelaysevaluation is a reasonable idea.
 Dave Abrahams Boost Consulting www.boostconsulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk