Hi Eric, >First let me say that I have limited bandwidth at the moment, and apologize in >advance for my short reply...
No need to apologize, I can understand this ;-) >And what you need is for the type of the Proto expression generated by >"(g1 || g2) && !g3" to be default-constructable? Have you tried doing >this with an expression adaptor and a domain in which child nodes are >all held by value (because reference members cannot be >default-constructed)? What errors did you run into? I'm sorry to tell you this, but I'm afraid you think I know much more than I really do ;-) Sounds great, but how would I do this? >I don't see how that could ever work. Any way you slice it, (_1 < _2) is >an expression, not a type. decltype(_1 < _2) could be made to work, for >some suitably defined _1, _2, and <. And yes, (_1 < _2) would need to be >default-constructable. Of course I don't think it could. I can still define an ideal and see how close I can get. >> std::transform(vec.begin(),vec.end(),vec.begin(), >> if_(_1)[ ++_1,return_(++_1)].else_ [return_(++_1)] ); >This just looks like Phoenix. Why can't you use it directly? It sure does, but I'm wondering if I'll be cheaper with phoenix than with my very simple grammar, which I at least about understand ;-) >> I have at least 2 more: >> >> - MPL. Great great library, but the template syntax is keeping too >> many away from it. >> I want what the FTMPL guys are doing (hi Matt, hi Zach). >> I'd really prefer to write _1 + _2 instead of plus<_1,_2> >You're talking about a complete C++0x redesign of MPL. Doable, but a big job. I'm not in a hurry and probably not alone with this idea ;-) >> - proto. Yes, proto itself. Eric talked about it in his BoostCon10 >> talk. Why not write >> when_() || when_() >> instead of proto::or< proto::when<>, proto::when<> > >> Now this is really perverse. A proto grammar to generate... proto. I love it! >I love it, too! Are you volunteering? ;-) A whole-hog redesign of proto >for C++0x, taking full advantage of decltype to allow syntax like that, >is one of those things I wish I had time for. Why not? ;-) Though my knowledge of proto is too limited to do it alone. I'd be happy to help though. This is the second reason I wrote my own mini-phoenix, learning by doing. >Exciting stuff! Truly Christophe, your ideas re decltype and EDSLs in >C++ are revolutionary. But unfortunately, I fear it will require a >revolution. This is all do-able, but the changes to MPL, Proto and even >to Phoenix in the case of the lambda capture stuff would require >breaking API changes. French have some experience with revolutions ;-) Seriously I bet quite a few would love to do it too and it could be great fun. Joel, Matt? *wink* :) >As for MPL and Proto, someone needs to sit down and do some hard >thinking about what meta-programming will look like in C++0x. I suspect >it'll look less like today's MPL and Proto, and much more like what you >envision. It's a huge opportunity for someone to do some really >ground-breaking work. After you write this, it won't be too hard to find candidates :) Christophe _______________________________________________ proto mailing list [email protected] http://lists.boost.org/mailman/listinfo.cgi/proto
