Boost logo

Boost :

Subject: Re: [boost] Phoenix Reloaded
From: Joel de Guzman (joel_at_[hidden])
Date: 2009-05-29 21:22:53

Eric Niebler wrote:
> I'm kick-starting the development effort to reimplement Phoenix on top
> of Proto. There's already been some discussion off-list among the
> interested parties, but there was general agreement to move the
> discussion here to do our work out in the open and possibly involve more
> people. To that end, I have ...
> ... created a Wiki page for coordinating our efforts:
> ... created a branch at branches/phoenix_v3. Anybody interested in
> helping out or just following along should do the following from
> BOOST_ROOT (trunk):
> cd boost
> svn co
> cd ../libs
> svn co
> There is nothing in boost/phoenix right now but stub headers, and
> libs/phoenix is simply copied from trunk/libs/spirit/phoenix.
> On the Wiki I put uploaded a miniphoenix.cpp file that demonstrates some
> ideas I have about what Phoenix-on-Proto might look like. Feedback is
> welcome.

First of all, thanks for kick-starting the development, Eric!

I looked at the prototype and it looks good. Reading the replies
to this post, I'd not worry about compile time too much at this
point but at least have a keen eye on it. I'd want to concentrate
more on the extension mechanism and its interface. To Alp and the
folks who came in later, let me explain...

Quite distinguishable in libraries that I wrote (Spirit, Phoenix
and Fusion), is that there are two APIs: 1) The user API and 2)
the extension API. The user API is what the user normally sees.
The extension API, is typically for advanced users. I as library
writer am a prime client of the extension API. The entire library
itself is built from that extension API. This is essentially the
core/kernel of the library. Making this extension interface as
simple and clear as possible, makes it is easier for other people
to contribute code. It also makes it a joy to port. Ideally, if the
proto port uses the same extension API as Phoenix-2, then all the
modules above the core could, in theory, remain as-is. Alas, this
is not possible due to a couple of reasons, but still, the
extension mechanism made Eric's task easier (I would say) when he
did the initial port to proto. Everything funnels through this
extension API. Port it and everything else follows.

At this point, I'd say that the design of the extension API is of
most crucial significance. I'll have some feedback on this as soon
as I learn more about the initial prototype. Those who have seen
or used my other libraries' extension interfaces (Dan, Hartmut, etc.)
please feel free to chime in.

More to come...


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at