Subject: Re: [boost] [Review] Phoenix V3: mini-review starts February 19th
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-02-01 08:26:21
Eric Niebler wrote:
> On 2/1/2011 7:28 PM, Hartmut Kaiser wrote:
>>> On 2/1/2011 5:59 PM, Eric Niebler wrote:
>>>> On 2/1/2011 1:30 PM, Thomas Heller wrote:
>>>>> Eric Niebler wrote:
>>>>>> Very exciting! Where are the extensibility hooks documented? I don't
>>>>>> see that in the documentation anywhere.
>>>>> That is the part that still needs to be documented ...
>>>> I don't see how we can do the mini-review until that part is
>>>> documented. After all, Phoenix was accepted only pending the
>>>> mini-review primarily because it needed those extensibility hooks.
>>> It is my understanding that the extension does will be ready by the time
>>> we have the mini review. If not, then I have to agree with Eric and
>>> postpone the review. The extension mechanism is a crucial part of
>>> Phoenix and one that sets it apart from Lambda. We should not diminish
>>> its role.
>> I fully agree. Thomas promised to have the docs finished by then. We
>> decided to be rather aggressive in terms of scheduling a) as we recognize
>> the need for having Phoenix available asap, and b) to put some pressure
>> onto Thomas
Exactly. Additionally, I have more time the next weeks cause my semester is
just ending right now.
I can assure i can address all open issues left.
> Fully complete docs would be awesome. Short of that, how about shooting
> for just giving people enough to talk about? A brief description of the
> directions in which Phoenix can be extended and some code examples
> demonstrating what it would look like. I think that would be enough to
> give the idea and let the review proceed.
I am not sure where to begin ...
At first, we have the extension point which was always there, that is
phoenix::function, it can be used to make your PFOs lazy.
Additionally, the mechanism to add other expression template generators and
to handle their evaluation is rather straightforward. Examples for that may
be found in the object and statement module. The reason these mechanisms
aren't documented yet is that I have the agreement with Joel de Guzman to
ease out the exposure to proto on that part. But the stuff and mechanisms
in place will continue to work. There will be two layers of "proto
exposure". The first will require no knowledge of proto, but of course is
limited in functionality. The second will be the "raw" proto interface,
allowing the user to use all of the power provided by proto.
The second layer exposes the most powerful new feature of phoenix:
These allow you to basically change the complete semantic of phoenix without
changing any line in the phoenix itself.
In fact, the default evaluation is handled that way, and you can replace
these actions by using the "raw" proto layer.
Examples are the defaul_actions itself, and there is the is_nullary action,
which calculates the wether an actor is nullary or not. Inside the scope
module, there is an example on how to replace the is_nullary action by
another one. I will provide a better example for that! Please be patient ;)
Also, please forgive the handwavy explanations above ;)
Last but not least, there are additional customization points:
- is_custom_placeholder and custom_placeholder:
Used to handle wrapper classes, and example on how to use it is
found at boost/phoenix/core/reference.hpp
This is the placeholder unification!
Phoenix can now handle all custom placeholders without much hassle
(yes, including the placeholders defined for boost.bind and
An example on how to use it can be found at
>> Thomas and I understand that if the docs won't be ready we will have to
>> cancel the mini-review.
> Say "reschedule", not "cancel". :-)
We will make it in time! Promise!
> And thanks for all your hard work,
You are welcome!
Besides, credit where credit is due, Phoenix V3 wouldn't have been possible
without Joel de Guzman and you Eric!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk