The formal review for FC++ has completed. I am sorry to say that FC++
is not accepted into boost at this time. It may be possible for the
library to be accepted in the future, but not without changes
substantial enough to warrant an additional review. I will describe
some possible strategies for later acceptance together with the
rationale for my decision. Note that while the library is not
accepted, the author has successfully established some of the merits
of the functional programming paradigm and we should not require him
to re-establish those same points in a future review. For that
matter, I'm not convinced that we should have asked him to
establish these points in the first place.
* Rationale
This was a very difficult decision, and I spent a long time sitting on
the fence. I believe that the functional programming paradigm is
important for C++ programmers, and that there are many interesting
features available in FC++ such as lazy lists and the standard prelude
functionality. In addition, though there was not a consensus amongst
reviewers to accept (see Opinions of the Reviewers below), several
boost library authors offered positive reviews of FC++. I finally
managed to gather my thoughts and come to a decision -- thanks to all
for your patience. In formulating my decision, I realized that one of
the important questions to ask of a candidate boost library is: "Can I
in good faith recommend to any C++ programmer with interest in domain
X that they spend the time and effort to learn library Y and consider
using it in relevant projects?" For FC++ I can not yet in good faith
answer yes. I do think that it is worthwhile for *some* programmers to
look at and would certainly consider pointing to FC++ in its present
form from the boost web site as an "interesting third party library" if
we maintained such links. But as I said I am not yet ready to put the
boost "brand" on FC++. Why not? My evaluation was based on two main
criteria, practicality and educational value, of which detailed
accounts follow.
** Evaluation of Practicality
Today FC++ is a largely monolithic library with a fair degree of
overlap with other boost components. This led to a good deal of
confusion/discussion during the review period. Such a state of
affairs (monolith with substantial overlap) could conceivably be
acceptable if there were clear problems for which FC++ was a uniquely
suited practical solution. Exact Reals (see footnote *** below)
notwithstanding, I don't believe that the *practical* value of FC++ as
a *monolithic* embedded DSL in C++ supporting mixed paradigm
programming has been satisfactorily established.
[footnote ***: The existence of clients such as the Exact Real lib
help demonstrate some degree of practicality. During the review I
briefly examined the Exact Real site. This looked like an interesting
application though I could not yet say how much practicality was
demonstrated since, for example, the performance characteristics of
lazy lists and constructive reals were not immediately clear to me. If
FC++ is to be accepted on practical grounds potential users may want
to be able to understand performance characteristics.]
If the authors were to break FC++ into smaller pieces and should they
participate in a future lambda, phoenix, FC++ merger then the above
concerns would be addressed. It surely doesn't hurt that the authors
of those other libraries expressed strong interest in the above
direction. And as was pointed out in the review some of the ideas from
FC++ might successfully be applied to other boost libraries such as
function and/or bind. If FC++ was part of a single consistent set of
FP components within boost then there would be good odds of achieving
consensus to accept. The changes to bring this about would be of
significant enough magnitude however that I would not be comfortable
with provisional acceptance today -- a future review (or
reviews of pieces are submitted independently) would be required.
** Evaluation of Educational Value
Since boost is not necessarily restricted to purely practical
libraries I also considered accepting FC++ into boost on the grounds
that it provides an environment in which C++ programmers can learn
more about and experiment with FP. FC++ enjoys some degree of success
in this area. However I found it disturbing that during the review a
number of traditional/imperative-style C++ programmers were just not
"getting it" about FP. Perhaps a case could be made for accepting
FC++ in its entirety on educational grounds after some of the
improvements suggested by reviewers were implemented,
e.g. improvements to the documentation and naming (useful in any
case), the completion of some additional features such as Monads, or
deeper documentation of the useful implementation techniques. But I
must admit that I find this strategy less attractive, and I would urge
you to try to break things up instead. One of the difficulties in
finding acceptance on purely educational grounds might be
characterized like this: if I was to recommend a way for an imperative
programmer to learn more about functional programming today I would
probably suggest a jump into an (OCa)ml, Haskell, or even a
Lisp/Scheme environment. I am not sure that this I would recommend the
FC++ environment for this purpose even with the changes suggested
above. That is, I am not entirely convinced of the *purely educational
value* of working with a functional programming DSL within C++. I
really would prefer to see the FC++ ideas used in a practical mixed
paradigm setting.
* Opinions of the reviewers
I was a bit concerned about the dearth of reviews during the first
week so I decided to extend the review. The final number of reviews
was still lower than I would have liked, but in the end I received
approximately 4 no votes and 7 yes votes, with varying amounts of
effort spent. Of the no votes, there was some support for acceptance
after a later review, pending certain improvements. At the same time a
number of the yes votes urged acceptance only after similar concerns
were addressed. From this one could argue that there was near
consensus that the community would be interested in accepting FC++
after these issues were addressed. The issues include the state of the
documentation, the monolithic nature of the lib, and the incomplete
nature of some components of the lib, e.g. monads. So I view some of
the yes votes and no votes as differing mainly on whether to accept
now with the above provisions or whether to require a second review
after the above concerns were addressed. I spent some time vacillating
between those options before finally settling on my decision to
require a second review before acceptance. Given the significant
nature of the requested changes I was only comfortable choosing the
latter option.
* Conclusion
Though I am sorry not to be able to accept FC++ into boost today I
would like to acknowledge its authors for the influence this library
has had on other boost components. I strongly encourage you to keep
working to bring the innovations from FC++ into boost in the future. I
would also like to acknowledge Brian for his many creative
contributions to the boost community and his thoughtful and
professional posts. I am sure that I am not alone in saying thanks for
all your efforts and I look forward to hearing more from you in the
future.
- Mat
