Scott Meyers wrote:
At BoostCon 2007, I was told that the functionality of Boost.Lambda was essentially present via Phoenix in Boost.Spirit. From what I can tell, both Lambda and Spirit/Phoenix will be present in 1.35, leading me to wonder what advice to give people who are interested in experimenting with the use of lambda functions in Boost. Are people to be encouraged to use Phoenix over Lambda, or are there features in Lambda that Phoenix doesn't have?
I'll be giving an overview of some Boost libraries at the Software Development conference in March, and I'll be showing some examples of Lambda. If I should be telling people to use Phoenix for future work, I'd like to know that.
It's interesting to note that Dave asked me a similar question: "If I were going to teach practical functional programming in C++, should I teach people Boost.Phoenix instead of Boost.Lambda? If so, why? " Here's my answer. It seems that it should answer yours? : In the context of Boost, I'd say it's better to teach Lambda as it is the official Boost library. Phoenix has some additional features beyond Lambda's so perhaps a short delve into those, in the context of the pending merger, will be good. All of current Lambda's API and all tests will be assimilated in the merger, so there's no fear that something will go away and be obsolete. Here's a short list of features in phoenix beyond lambda: * Lazy Functions (http://tinyurl.com/yvjo7p) makes it easy to adapt bindable polymorphic function objects. This, IMO, is crucial in writing extensive generic lazy function libraries. * STL lazy functions for STL containers and algorithms. The full suite of container functions (begin, end, back, front, push_back, insert, etc.) and algorithms (accumulate, for_each, find, find_if etc.) are provided out of the box. These are all Lazy Functions counterparts of the STL functions. * Modular Design. Phoenix has a well thought and properly documented extension mechanism (http://tinyurl.com/ynqpgg) based on key concepts. All Phoenix components are models of these concepts. The extension mechanism is crucial in Phoenix's design. At least one Third party FP library uses this mechanism to good use (can't recall the name ATM, but I can find it if needed). It's also a big reason why there are more contributors to the codebase (including Daniel Wallin who helped in the scopes and local variables, Dan Masden STL algorithms and Angus Leeming STL intrinsic functions, etc.). Does that help? Here's the Phoenix2 docs: http://spirit.sourceforge.net/dl_more/phoenix_v2/libs/spirit/phoenix/doc/htm... Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net