| What is your evaluation of the design? It seems useful (if a reflection of underlying limitations in the C++ language) and doesn't fight too much with STL concepts. There is some overlap with STL and other Boost libraries like lambda, but the gains are worth any duplication. | What is your evaluation of the implementation? Seems to work OK. | What is your evaluation of the documentation? Good selection of helpful examples (but could be commented better). Better than one might expect considering the difficulty of the concepts. A whole book could easily be produced :-) | What is your evaluation of the potential usefulness of the library? Extends the scope of C++ significantly - but I am unsure quite how many people will use it at first. (Like the STL, it requires some change of mindset). | Did you try to use the library? Yes, briefly with a few of the many sample programs. | With what compiler? MSVC .net aka 7.1 (mainly with std for loop scope, warnings level 4 (strict) | Did you have any problems? Some warnings, mostly spurious but potentially annoying, and probably easily removable. | How much effort did you put into your evaluation? An couple of hours digesting the pdf paper and an hour or so trying test programs. | Are you knowledgeable about the problem domain? Enough to see its potential - but probably not its pitfalls? | Overall: I vote for acceptance into the Boost library. Paul A Bristow Some observations, mostly minor: 1 I have tried a few sample .cpp files and the ones I have tried all compile and run as expected, although most with some warnings (see below). This makes me optimisitic that all will compile with MSVC 7.1, but I hope someone with more time will confirm this. Although there are many useful and informative tests (some using the essential Boost test suite) I feel it would also be useful to have a single test suite (or a few) which are suitable for routine regression testing. It would be nice to reduce warning noise (provided it is not too much trouble). Although MS users rarely use 'strict' for 'production' code because Windows requires non-strictness, I believe strongly that it will increase portability to try to get code that is accepted by all compilers in strict mode. A Pre-emptive strike? For example, compiling Example.cpp Msvc 7.1 (warnings level 4, no language extensions aka strict) produces some warning 'noise' at: const T operator*() const { return l.head(); } "qualifier applied to function type has no meaning; ignored A qualifier, such as const, is applied to a function type defined by typedef. Example // C4180.cpp // compile with: /W1 /LD typedef int *FuncType(void); // the const qualifier cannot be applied to the // function type FuncType const FuncType f; // C4180" i:\FCpp\list.hpp(510) : warning C4180: qualifier applied to function type has no meaning; ignored i:\FCpp\list.hpp(527) : see reference to class template instantiation 'boost::fcpp::impl::list_iterator<T>' being compiled i:\FCpp\list.hpp(1042) : warning C4180: qualifier applied to function type has no meaning; ignored i:\FCpp\list.hpp(1059) : see reference to class template instantiation 'boost::fcpp::impl::strict_list_iterator<T>' being compiled However, this is a level 1 warning, so Microsoft obviously believe it is wrong C++. And also i:\FCpp\curry.hpp(131) : warning C4512: 'boost::fcpp::impl::binder1of2<Binary,Arg1>' : assignment operator could not be generated with [ Binary=boost::fcpp::impl::XPlus, Arg1=std::string ] i:\FCpp\full.hpp(82) : see reference to class template instantiation 'boost::fcpp::impl::binder1of2<Binary,Arg1>' being compiled with [ Binary=boost::fcpp::impl::XPlus, Arg1=std::string ] FC++example.cpp(34) : see reference to class template instantiation 'boost::fcpp::full1<F>' being compiled with [ F=boost::fcpp::impl::binder1of2<boost::fcpp::impl::XPlus,std::string> ] i:\FCpp\full.hpp(102) : warning C4512: 'boost::fcpp::full1<F>' : assignment operator could not be generated with [ F=boost::fcpp::impl::binder1of2<boost::fcpp::impl::XPlus,std::string> ] (Which perhaps might be supressed by inheriting from Boost::noncopyable??? - I am NOT an expert on this!) Cute_compose)syntax required language extensions because not linked with the separately compiled Boost test library. Some examples might be more quickly understood by the 'functionally challenged' with the output as a comment, for example: // Test automatic currying. cout << f(3)(5) << endl; // 3 + 5 = 8 Another nitpick is that the files don't follow the Boost guideline: o A comment line describing the contents of the file. I really like this style: #include <iostream> using std::cout; using std::endl; Which shows immediately what is being used from each include file. In some cases replacing: using namespace boost::fcpp; With using boost::fcpp::list_with; using boost::fcpp::list; using boost::fcpp::tail; using boost::fcpp::take; using boost::fcpp::compose; using boost::fcpp::enum_from; might also be more helpful. Is there a Boost convention for the order of include files? I always but the std library includes first, but I note that these examples include FCpp modules first, before std, for example compose2.cpp #include "prelude.hpp" #include <iostream> I think I also found a file which didn't end with a 'return' and so failed to compile in 'strict' mode (but I can't remember which). Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow@hetp.u-net.com Sent: 13 February 2004 19:14 To: boost@lists.boost.org Subject: [boost] FC++ Formal review is now in progress (2/13-2/23) The formal review of fcpp by Brian McNamara and Yannis Smaragdakis is now in progress, runiing from Friday February 13th at 12 noon, PST and and run to Monday, February 23rd, 12 noon PST.