[boost] Re: FC++ Formal review is now in progress (2/13-2/23)

From: Andy Little (andy_at_[hidden])
Date: 2004-02-19 05:17:39

"Mat Marcus" <mat-boost_at_[hidden]> 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