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: Christophe Henry (christophe.j.henry_at_[hidden])
Date: 2011-03-14 17:12:09

>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