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

From: Eric Niebler (eric_at_[hidden])
Date: 2008-06-30 13:13:31

David Abrahams wrote:
>>> Here are the parts and topics that I see as being in the category:
>>>
>>> result_of
> 
> * Too hard to define result<> templates for polymorphic function objects.

Agreed. I've written my own Egg-like function object adaptor to do the 
"right thing" with lvalues and rvalues. It lives here:

http://svn.boost.org/trac/boost/browser/branches/proto/v4/boost/proto/detail/poly_function.hpp

It is a polymorphic function object wrapper around a template that 
generates monomorphic function objects. (So it's analagous to 
mpl::quoteN, which turns a metafunction into a metafunction class.) It 
forwards reference-wrapped arguments to the monomorphic implementation 
as lvalues, and all others as rvalues.

TODO: replace all Proto's function objects with this wrapper to enforce 
consistent behavior. All function objects across Boost that need to make 
rvalue/lvalue distinctions would need to be examined for consistency in 
this regard. Joel, I'm looking in Fusion's general direction.

> * A whole spate of questions that came up in
> http://article.gmane.org/gmane.comp.lib.boost.devel/173370 were not
> answered with a page of documentation, utility library, or other
> facility.  I still don't know what the upshot was

I still don't know either, sadly, but I think a wrapper like the one 
above that makes it easy to author polymorphic function objects that 
consistently handle lvalues and rvalues is a good first step.

<snip>
>>> lambda/phoenix/bind
> 
> * Incompatible placeholders
> * Been waiting for the lambda/phoenix merger forever
> * Lambda has lots of limitations and gotchas that we can improve on now
> * Phoenix 2.0 not in Boost

I've already taken the first and (IMO) most important step here by 
porting both Lambda and Phoenix to Proto. My opinion on the unification 
of Lambda and Phoenix is that it shouldn't happen. There are too many 
subtle differences in semantics. Rather, Lambda should be retired and 
Phoenix should be promoted (after being reviewed, etc.). The 
placeholders should be Proto terminals shared across Phoenix, Bind, 
Xpressive, Spirit and any other library that needs numbered 
placeholders. This sort of unification was, after all, one of the major 
design goals of Proto in the first place.

Boost.Lambda Proto port:
http://svn.boost.org/trac/boost/browser/branches/proto/v4/libs/proto/example/lambda.hpp

Boost.Phoenix Proto port:
http://svn.boost.org/trac/boost/browser/branches/proto/v4/boost/phoenix

Still TODO: finish Proto v4 and get it in trunk. Improve the compile 
times of Phoenix/Proto and get it in the review queue. Then get Bind 
working with the Phoenix/Proto placeholders.

<snip>

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com