30 Jun
2008
30 Jun
'08
7:08 p.m.
Apologies for overquoting... On Jun 30, 2008, at 1:13 PM, Eric Niebler <eric@boost-consulting.com> 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?