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

From: David Abrahams (dave_at_[hidden])
Date: 2008-06-30 15:08:25

Apologies for overquoting...

On Jun 30, 2008, at 1:13 PM, Eric Niebler <eric_at_[hidden]>  
wrote:

> 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.

Great, but one important thing is missing: it isn't in boost as far as  
users are concerned.

>
> <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.

Kewl!

> My opinion on the unification of Lambda and Phoenix is that it  
> shouldn't happen. There are too many subtle differences in semantics.

I guess you're in a position to know

> 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.

As long as they're objects and not types ;-)

> 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.
>

On old compilers, too for bind... Should be fun.

So does this mean you're taking on the functional programming part of  
the amorphous issue I raised?