[boost] [Review] Phoenix

Subject: [boost] [Review] Phoenix
From: John (phillips_at_[hidden])
Date: 2008-09-29 19:44:49

  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.

  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 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.

            John Phillips