Boost logo

Boost :

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

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