"Mat Marcus" <mat-boost@emarcus.org> wrote
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.
Do you think the library should be accepted as a Boost library? My view on current state of the boost libraries is that it is a compendium of non related stuff. Some fine but non core C++ applications e.g Python, Spirit, and some C++ utilities type traits, mpl. Based on that I see no reason to exclude this as it seems to be a popular library among regular boosters. It neatly fits into both categories. It (ab)uses C++ operators to try to become its own mini language. If the boost library is to remain monolithic however the increase in download size of the next version of the library is an interesting forecast. Are you knowledgeable about the problem domain? No functional programming is not my 'thing'. One criticism of my brief look is that it seems to be a solution in search of a problem. But attempting to shoehorn it into C++ has led to some pretty ghastly syntax. If this is intended to lead C++ programmers to Haskell ... which appears to be one goal then it might be better to just point them at a Haskell download. But of course... good ole C++ can handle this sort of abuse with ease ... :-) What is your evaluation of the design? My evaluation is based partly on comments from Brian McNamara. He seems to acknowledge that the current version would benefit from some radical pruning. The list utilities seems to lie at the core of the library. So one approach might be to prune it right back to some 'list utilities'. Maybe this would help to focus potential users on one core use. A much more interesting and useful library might be the result. The 'pass by value' problems seems to be one effect of trying to shoehorn concepts from another language into C++. This is not what C++ is about. Maybe the library has been implemented in the wrong language? As noted before the resulting syntax is horrible to read. What is your evaluation of the implementation? No comment. I have not tested. I havent perused the docs enough to see if there is any mention of performance(speed). Both at compile time and run time. As it must use a fair amount of metaprogramming I would expect compile times to be long. Therefore I would hope for a significant runtime benefit in speed. What is your evaluation of the documentation? The interesting thing about the documentation is that it may lead me and others to Haskell. (Perhaps that is the point? ) One comment in the Docs re Haskell separation of types and objects is interesting. This is classically one thing C++ doesnt do . I hope to look further into this to see what the benefits and tradeoffs are. (No, I'm not suggesting C++ go down that road :-) ) What is your evaluation of the potential usefulness of the library? Currently I would tend to avoid it. It would require a lot of time and effort to relearn how to do things that I could better spend elsewhere. Did you try to use the library? No How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I have spent around 1/2 hour looking at the Docs. ( I hope to go back and read some more) My current assessment from reading is that the best way to go about 'functional programming' might be to go direct and learn Haskell. Overall though I do appreciate the time and effort that has gone in to it. It just happens to be not for me. regards Andy Little