Boost logo

Boost :

From: joel de guzman (djowel_at_[hidden])
Date: 2002-03-22 19:37:54

----- Original Message -----
From: "Paul Baxter" :

> Can Joel comment now about his intentions?
> That seems like it might clear some of the confusion surrounding this.
> Is the license likely to be outside the bounds of Boost's requirements?
> Does Joel et al have a desire to submit to boost with its attendant coding
> guidelenes etc.?

As I said in my other post, once the code stabalizes, I'll be glad to
submit Phoenix if it is still possible to so.

Phoenix is already boostified (as Spirit is too). We use both Phoenix
and Spirit in the boost directory. All (most) of the coding
conventions are followed. The licensing is compatible, we use the
underlying boost libraries (if at all possible), etc. The only thing
that's still not done is to place both Spirit and Phoenix under
namespace boost. I think it's not a sensible thing to do because
neither are boost libraries yet.

If you read my other post, I voted *for* LL inclusion here and now. LL
is a mature library and many people should benefit from such a library
sooner and not later. It is my opinion that LL satisfactorily
fulfilled its goals and objectives. As a library writer, I may have
differing needs and LL might not be the tool I am looking for, but for
90+% of users, LL is just the right tool.

However, here's my dilemma (perhaps it's better to say this now): We
(the group behind the Spirit inline parser) are preparing for a formal
boost submission of Spirit. We are very close. We are now at version
1.3.x. As soon as we get to v1.4.x, we will ask for a formal review.
Although Phoenix is stand-alone from the main Spirit code, we might
have to package it along with Spirit (Phoenix is a Spirit sub-project,
BTW). There are some important issues that LL does not address yet.
One important issue is extensibility (I've posted my opinions
regarding this). Phoenix is designed to be extended. That might not
mean much to the typical programmer who wants to use it as a
replacement for STL's binders, but for library writers like me, this
is crucial. There are other concerns; I guess I don't have to restate
them here, please see my previous posts.

Thanks and regards,

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