Re: [boost] Review: lambda library

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,
--Joel