Boost logo

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

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