Proto for Boost mailing list page: Re: [proto] My own lambda for MSM / wish list

Subject: Re: [proto] My own lambda for MSM / wish list
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-03-16 03:49:00

On Monday, March 14, 2011 10:12:09 PM Christophe Henry wrote:
> >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).

Well, because it wasn't possible at the time, I assume ;)
Times have changed since then ... 

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

Sure ... the things about return types can't be found in the examples ... To 
quote the docs:

"Unlike lazy functions and lazy operators, lazy statements always return 
void."
https://svn.boost.org/svn/boost/trunk/libs/phoenix/doc/html/phoenix/modules/statement.html

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

In general, no, because of various terminals that need to be initialized.
You can however limit the phoenix grammar to only those expressions that can 
be default constructed.
Why not copy construct them?

> - what is the return value of a phoenix expression?

boost::result_of<Expr(Arg0, Arg1, ..., ArgN)>::type

This is a little hidden in the docs ... but its all here:
https://svn.boost.org/svn/boost/trunk/libs/phoenix/doc/html/phoenix/inside/actor.html

Follow the link to "Polymorphic Function Object".

> - how do I add stuff I want (return for ex.)

https://svn.boost.org/svn/boost/trunk/doc/html/phoenix/examples/adding_an_expression.html

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

Well, the phoenix internals are all implemented using proto ... if you dive 
deep into the actions you need both, stuff from proto and stuff from 
phoenix. This part of the library is just proto using stuff that was defined 
within phoenix ... 
You need to know what the evaluator and what actions are:
https://svn.boost.org/svn/boost/trunk/libs/phoenix/doc/html/phoenix/inside/actor.html#phoenix.inside.actor.evaluation
https://svn.boost.org/svn/boost/trunk/libs/phoenix/doc/html/phoenix/inside/actions.html
 
> 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?

Yes, the entry point is pretty high, but i hope its worth it ... If you come 
to the conclusion that writing your own library is faster and easier phoenix 
maybe isn't quite ready for prime time with that respect.
I am looking forward to improvments in the docs, or additions to code you 
might have!

> 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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/proto