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