Boost logo

Boost :

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

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


> 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:
> Boost.Phoenix Proto port:
> 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?

Boost list run by bdawes at, gregod at, cpdaniel at, john at