Re: [boost] [Review] Phoenix

Subject: Re: [boost] [Review] Phoenix
From: Joel de Guzman (joel_at_[hidden])
Date: 2008-09-29 23:09:03

John wrote:
>   First, the big question
> 
>   I vote for a second fast track review of the v3 implementation.
> 
>   The reasoning is simple, if a little painful. I have a lot of sympathy for
> the view that we should be reviewing the version that is actually going to
> be released (or at least something close to it). Joel is right that some
> libraries have been admitted with the condition of large changes. In
> general, given the exceptional quality of his work to date, I also consider
> him quite trustworthy when he says that is what he plans to do. However, I
> have problems with how I'm supposed to review the implementation of a
> library that won't be implemented the same way when it goes into Boost.

Understood.

>   That said, even the v2 edition is an exceptional library. It has been
> pointed out elsewhere that there are some current details missing from v2,
> and Joel has already promised their inclusion in v3. Aside from those
> artifacts of its history, it is a very nice piece of work. I have used it in
> a few projects and I find it clear to use, well documented and largely well
> behaved (except for afore mentioned problems). It works on compilers that
> live close enough to the standard, and that happens to be what I currently
> use. It is well documented (I also vote for the return of the section on
> FP.), and I enjoy the style. There is a lot to learn to use the library
> well, but that is partially because it is a powerful library in a
> programming idiom that many of us have only learned we need recently.

It's reasonable to have more background on FP in the docs. I'm
an advocate of it anyway, so I'll be pleased to provide more
material on the subject -- at least the practical side of FP.

>   It is practical, and so provides a gentler step into functional
> programming than would be the case if it stressed purity. However, it allows
> clearly functional constructs and has well thought out abstractions
> underlying the interface
> 
>   The reasoning is painful because it has me voting against immediate
> inclusion for a library I obviously like and respect. However, I think this
> review is valuable for what it accomplishes. In my following of the
> discussion so far, I haven't seen anyone who has issues with the need for
> the library, with the basics of the interface, or with the abstractions it
> embodies. I think this is the 85% good stuff (I may be remembering the wrong
> number here.) that Joel spoke of. That allows us to focus the fast track I
> am voting for on the implementation and compliance with a few specific
> changes.
> 
>   v2 will be available, and the small breaking changes in v3 will be the
> first boost release (since I'd be very surprised if Joel didn't do all
> requested and more for v3), so there will be a minimal legacy code base
> issue.
> 
>   As for the naming, I would also like to see the release version become the
> new Lambda v2. Though I appreciate creative names for some things, it seems
> to cause problems for software libraries.

Thank you for your review.

Regards,
-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net