Re: [boost] phoenix::bind

Subject: Re: [boost] phoenix::bind
From: Joel de Guzman (joel_at_[hidden])
Date: 2008-10-02 22:36:30

Peter Dimov wrote:
> Steven Watanabe:
>> Joel de Guzman wrote:
>>> Yep. Phoenix can do that. A local variable may hide an outer local
>>> variable. Here, we just reuse the locals for arguments to the
>>> lambda as well. So, in current terms, this:
>>>
>>>     lambda( _x, _y )[ _x + _y ]
>>>
>>> is just this:
>>>
>>>     lambda( _x = _1, _y = _2 )[ _x + _y ]
>>
>> Am I misunderstanding something?  I thought that this would give
>> lambda( _x = _1, _y = _2 )[ _x + _y ] (1, 2)() == 3
>> instead of
>> lambda( _x = _1, _y = _2 )[ _x + _y ] ()(1, 2) == 3
> 
> Under the model I have in mind:
> 
>    lambda( _x, _y )[ _x + _y ] ( 1, 2 ) == 3
> 
> That is, lambda is not lazy, and it doesn't compose further.
> 
>    lambda( _x )[ _x ] + _1
> 
> doesn't compile; there's no operator+ taking a lambda.

Again, there's a problem with this behavior and the
higher-order argument ala for_each. But maybe not. I'm
starting to investigate. There was a time that this was
allowed:

     phx::for_each(_1, std::cout << _1 << std::endl) (vec)

The f is an implicit lambda. Not saying that this is good, but
just to show that it's possible to detect the scope of the _1
on the left and on the right. Explicit lambdas would be the
same, me thinks.

>> I don't think it is quite the same if you use an arbitrary expression
>> instead of _x + _y.  For instance, what should this mean:
>>
>> lambda(_x, _y) [ _x + _y + _1 ]
> 
> If we're allowed to not think about backward compatibility, I'd say that 
> _1 would no longer exist. Not even at top level.

Right! _1 would not make sense because essentially all the arguments
are declared already in the lambda declarator (_x, _y).

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net