Re: [boost] Phoenix v3 review

Subject: Re: [boost] Phoenix v3 review
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-02-25 08:13:08

On Fri, Feb 25, 2011 at 1:31 PM, Mathias Gaunard
<mathias.gaunard_at_[hidden]> wrote:
> On 24/02/2011 19:07, Thomas Heller wrote:
>>
>> On Thu, Feb 24, 2011 at 5:52 PM, Mathias Gaunard
>> <mathias.gaunard_at_[hidden]> Â wrote:
<snip>
>> It is not redundant. The thing is that proto only recognizes one tag
>> for a terminal expression. To distinguish between all those different
>> terminal types, we needed the custom terminal customization point.
>
> I was thinking phoenix::ref could be a proto node, but that doesn't quite
> work because Proto catches terminals by value (isn't there a way to
> customize that though? -- I'm not familiar with that kind of thing)

There is a way in proto to control the capturing behavior on a domain
basis. The Phoenix AST nodes need to be captured by value by default.
Otherwise there will be dangling references all over your code.
The only way to have both by value and by reference is to realize the
latter with a terminal wrapper. Fortunately there already exists
something like this for exactly that purpose:
boost::reference_wrapper. Now, to distinguish between "normal"
terminals and this wrapper, we developed the custom terminal
registering method. As a matter of fact, it came in handy in all kinds
of different situations (It is used for the null expression, and it
got very handy in the spirit port).

>>
>>> Phoenix as Proto with statements
>>> --------------------------------
>>>
>>> One thing I was hoping Phoenix v3 would be is Proto extended to support
>>> statements.
>>
>> I don't understand, what do you mean by that?
>
> Proto is a tool to write domain-specific embedded languages based on C++
> expressions.
> It's like a compiler framework, but the AST is limited to expressions and
> cannot contain function creation, local variable definition, or repetition.
>
> It would be nice to have a tool like Proto but that was extended to deal
> with more C++ language constructs. Even if the syntax to call them requires
> transforming those constructs to expressions with a DSEL of its own, at
> least there can be a canonic way to do so.

This already exists inside proto, there are basic language constructs
and it is easily extensible (through proto transforms).

>>> While it comes pretty for some uses, it still fails one one point: the
>>> ability to define custom languages that embed Phoenix statements.
>>
>> The ability is there ...
>>
>>> The missing piece is handling of domains (extends are missing too, but I
>>> don't think they make sense at the statement level).
>>
>> ... and you don't need necessarily need the proto domain feature for that.
>
> Phoenix doesn't really help with things like
>
> phoenix::if_(1)[some_expr_in_my_own_domain]

It is not really the job of phoenix. For things like that you need go
to the "low-level" proto layer. See below.

> If things are necessarily in the phoenix domain, that's not really your
> custom language.
> That's like using Proto without domains.
> I think it needs to be a parametric domain, like phoenix of common domain of
> what's inside.
>
> Being able to tell how Proto expressions within Phoenix should be evaluated
> on a per-domain basis seems important too.

Which can be done, see below.

> I have no idea how to evaluate a Phoenix expression containing other Proto
> expressions with the current design.

You can hook up your DSEL into phoenix by extending meta_grammar and
default_actions.
Maybe a small example in the documentation would be helpful to explain
how it really works ...

>
>>> Documentation
>>> -------------
>>>
>>> <http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/html/phoenix/actor.html>
>>> doesn't talk about perfect forwarding.
>>
>> It is mentioned here:
>>
>> http://svn.boost.org/svn/boost/sandbox/SOC/2010/phoenix3/libs/phoenix/doc/html/phoenix/inside/actor.html#phoenix.inside.actor.function_call_operators
>
> Yes, but the page I referenced shouldn't only list non-const reference
> overloads: that's confusing.
>
>
>> We can only *emulate* perfect forwarding. THe sentence you claim is
>> wrong is just a reformulation of the "Perfect Forwarding Problem"
>> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm)
>> problem statement.
>
> Then the original problem statement is misleading.
> It is later said in the paper that they don't consider solutions that scale
> worse than linearly to be good enough.
> Solution #3, that they do list, works fine with C++03 language rules, but is
> discarded due to its cost in number of overloads.
>
> I don't really see where the term "emulation" comes from. Forwarding
> arguments is forwarding arguments, you just have to make sure you can catch
> all arguments without loss of information, there is no hack or emulation
> involved.
>
> A better phrasing would involve saying that is is not impossible, but rather
> requires an impractical amount of work.
> I wonder how much that amount of work is really a problem with preprocessed
> Phoenix though.

Preprocessed phoenix still needs to resolve all the operator overloads.
The other points you mentioned will be reworked.