Re: [boost] [range/iterators/algorithms/phoenix/bind...] Coordinated Approach

From: Joel de Guzman (joel_at_[hidden])
Date: 2008-07-01 22:12:56

Eric Niebler wrote:
> Giovanni Piero Deretta wrote:
>> Yes please. The only thing that prevents me to use Phoenix every day
>> is the fact that it is not an official boost library. If it were to
>> become 'first class' personally I would be glad to ditch lambda.
>>
>> Still I do not think that having both libraries for only one release
>> is enough, probably boost should carry both of them for a while (3, 4
>> releases), with explicit deprecation makers. Boost.lambda is a big and
>> complex library, and it might take time to do a good conversion.
> 
> I agree.

Yep. Just like Spirit "classic" will stay around for quite some time
still.

>> - Last time I checked Phoenix only had a monomoprhic bind. If you have
>> polymorphic functions you have to convert them to lazy functions. I
>> think that adding a polymorphic bind (like lambda shouldn't be hard).

Boost.Lambda has polymorphic bind? How can it do that? Bind is
inherently monomorphic. What am I missing?

>> - Would it be possible to tell Phoenix the default capture mode, like
>> in C++0x lambdas? By default lambda[] ( or any implicit lambda
>> expression) would capture by value, but something like lambda_r[ ] (_r
>> for reference) would get rid of many ref/cref at least for upward
>> funargs. I do not know how easy is to do it, but I guess that proto
>> make it possible (in fact I think that the reverse would be easier:
>> capture by reference by default and then a top level lambdac would
>> traverse the expression and convert any implicitly captured reference
>> to a copy).
> 
> An interesting suggestion. Joel?

Good ideas. It would help to provide code snippets/use cases.

>> - What are exactly the quirks that makes it hard to have full backward
>> compatibility? Well except for 'sig' of course.
> 
> Wish I had written them all down. One that sticks in my mind is whether 
> variables are captured by value or by reference. With Phoenix, it's very 
> consistent ... all variables are captured by value, always. Lambda tries 
> to be a bit more helpful, and it makes the rules more confusing, IMO. 
> Most of the time, variables are captured by value, but a variable on the 
> left of an assignment is captured by reference. This includes all the 
> assignment operators, like plus-assign. So the following is a valid 
> lambda expression:
> 
>    int i = 0;
>    i += _1;
> 
> But in Phoenix, it would have to be:
> 
>    int i = 0;
>    ref(i) += _1;

Yep. I personally find this one rather quirky. Another is the
->* syntax, and yet another is the "protect" feature in lambda
that's supplanted by the more powerful 'lambda[]' syntax and
the 'let' feature (local variables) in phoenix.

There are some more, but I have to go through the tests and code
to list them down.

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