>Calling phoenix expressions from the statement module return void. >Calling phoenix expressions from any other modules return whatever ... >depending on the "C++-Sense".
It's ok, I can live with it, though I'll need to find a way around because I do need this return stuff. >> If you allow a short criticism, I'd say that phoenix is great and >> maybe even offers all I want, but the doc is doing it a great >> disservice. I got so frustrated I started my own implementation and >> seeing my lack of time, it means something ;-) >Maybe you should have asked before you started re-implementing everything ;) And maybe I did ;-) As a matter of fact, I did, twice. First at the BoostCon09 I talked about it with JdG, but my question was not well formulated, so I'm not sure he got what I wanted to do. Second time at BoostCon10, I mentioned it during my talk and Eric's view was that what I wanted to do was not possible with the state of Phoenix at that time (though maybe I again failed to explain my point). Then I had a look at the doc and still didn't find my answers. So, I decided to invest some time (not too long) to present using a basic implementation what I was looking for. At least with this example, it's easier to discuss, I can ask much more targeted questions and I had a lot of fun in the process :) >Phoenix comes with a whole bunch of testcases, which can be seen as examples >as well. I had a look at that too, but I looked at the "statement" testcases, which still didn't answer my question about return types. True, I didn't think of looking into "operator". >I tried to document the internals. What do you think is missing? >The questions you had could have all been solved by looking at the >documentation, there wasn't any need to know the internals. What I wanted to know: - can I pass a phoenix expression to a decltype / BOOST_TYPEOF and default-construct it? - what is the return value of a phoenix expression? - how do I add stuff I want (return for ex.) Do I really find this in the doc? With the ref/cref inside the lambda, it's also not shown, but I admit I could have thought about it by myself. >Ok, I admit, the whole capture by value semantics probably isn't discussed at >full length. >Of course there is always room for improvement! Do you have anything specific? Ah, value semantics isn't my main interest anyway. Where I really started to doubt was reading the internals section, then I came to this: // Transform plus to minus template <> struct invert_actions::when<phoenix::rule::plus> : proto::call< proto::functional::make_expr<proto::tag::minus>( phoenix::evaluator(proto::_left, phoenix::_context) , phoenix::evaluator(proto::_right, phoenix::_context) ) > {}; I understand a bit of proto but this mix of proto:: and phoenix:: is just killing me. It just doesn't fit into my standard design layered model. Either I work at the proto layer, or at the phoenix layer, not at both. Having to understand both is simply increasing the cost of playing with phoenix. Now, I have the feeling you think I'm here for a round of phoenix bashing. It can't be less true. I'm a big admirer of Joel's work and I think phoenix is a really cool library. My problem is simple, I want to combine ET with decltype and bring it into new places (MSM, MPL, proto for example), and I need to answer 2 questions: - can phoenix fulfill my needs? (it seems it does, great!) - do I arrive there faster than with my own grammar as phoenix's cost of entry is pretty high? Ok, I'll give a second try to phoenix and see how far I can go. Thanks for your answers, Christophe _______________________________________________ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto