Re: [Boost-users] Relationship of Lambda and Phoenix

From: Joel de Guzman (joel_at_[hidden])
Date: 2008-01-31 19:45:36

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/html/

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