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