[boost] Re: Review Request: FC++

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