Hi,
It was quite difficult to review this submission for several reasons:
mostly because (from POV) it has virtually no documentation, no structure,
no testing and what is most important no clear defined problem domain, where
this library provide a solution (here I mean not the function objects
facilities, but namely FP part of the submission). What it does have, is a
several interesting ideas. In summary it my opinion this submission is
unacceptable and my vote is NO.
Problem domain
-------------------------------------------------------------------------
Unlike my usual review I would like to start with problem domain
discussion. Library position itself as a library to do FP in C++. Namely in
this order. Kind of like library for crazy Haskell programmer that for
whatever reason decided to use C++. Docs (and papers) in details describe
how to do things one could do in Haskell using FPC++ analogs. There is even
comparison of performance with Haskell compilers: not to worry we almost as
fast. For me as a C++ programmer more important is to see the comparison
with the same algorithm implemented with other usual C++ techniques. I did
one myself. I took an example used by authors for performance testing and
modified it like this:
.... here is what is already in test
////////////////////////////////////////////////
inline bool is_prime( int i )
{
for( int c = 2; c <= i/2; ++c ) {
if( i % c == 0 )
return false;
}
return true;
}
inline int nth_prime( int N )
{
int i = 1;
while( N > 0 ) {
i++;
if( is_prime( i ) )
N--;
}
return i;
}
int main() {
acc_timer timer; // acc_timer is my timer class based on gettimeoftheday
int NUM;
cout << "Num primes = ";
cin >> NUM;
timer.start();
list<int> l = primes(NUM);
int i = at( l, NUM-1 );
timer.stop();
cout << i << endl << "took " << timer.elapsed() << " sec" << endl;
timer.start();
i = nth_prime( NUM );
timer.stop();
cout << i << endl << "took " << timer.elapsed() << " sec" << endl;
}
The algorithm I am using similar to the one use by original code. The only
difference is that I am not using FC++ abstraction. I was using gcc 3.3.1
under cygwin on my Athlon 2000+ PC. I was using following command for
compilation:
g++ -O4 -I [list of include directories] tw_primes.cpp
Here is the result of several runs:
Num primes = 500
3571
took 4.825 sec
3571
took 0.015 sec
Num primes = 750
5693
took 11.703 sec
5693
took 0.036 sec
In average FC++ solution is 320 times slower. For any practical usage
price of an abstraction should not exceed 10-20%. With price as high as FC++
currently shows I wouldn't even start to think in this direction.
In general from my experience usage of lazy evaluation quite limited (in
FP sense - I do not mean binding the arguments, which is widespread). It may
be used sometimes, but I know many more other neat tricks that are more or
as useful. IMO authors need to justify need in lazy list as a generic
reusable components in C++ (namely in C++ not for FP which says nothing to
me), but for now I do not see a place for them. Some papers does try to
justify need for FP to implement common design patters in C++. But actually
they only shows need for use of polymorphic functors nothing more.
Design
-------------------------------------------------------------------------
I with almost everything authors says about need of polymorphic functors
and the way they design support for result type deduction. But I believe it
should be boost-wide solution. With support in both boost::function,
boost::bind and boost::lambda.
I don't think we need indirect functoids (with their virtual functions and
smart_pointers inside). boost::function should be made result_of aware
instead.
I couldn't comment on design of lazy lists since it does not described in
docs. But I still not convinced that there exist a problem to justify need
for this construct.
Lambda facilities design is also offsite and it's difficult to comment on
it by itself and on comparison with boost::lambda. In my personal opinion
there should not be two different facilities dedicated to the same cause
within boost. If you have any issues with boost::lambda lets resolve them.
In other case it would only source of confusion to the users and make them
both less useful.
Monads are not covered and not commented accordingly.
Explicit built-in currying (I prefer term binding) looks like convenient
idea and I would vote to include this info boost::function
Implicit built-in currying on the other hand like more like a source of
confusion than convenience and in my opinion should not be included. It not
only may confuse inexperienced user, but also may cause a conflict If I have
function polymorphic not only in regards to the type of the arguments but
also in regards to their number.
I do not understand need for separate notion of thunks. Why couldn't we
just bind all function arguments using usual means?
Library supply the collection of predefined function object. While I can
blindly accept polymorphic counterparts to the STL functional ones, the rest
should be documented and discussed one by one (the fact they belong to
mythical "prelude" says nothing to me). Also from sources it looks like many
of them operate on lazy lists. Why couldn't we have them as a member
functions? They are not generic to be used for different kinds of lists
(like STL list) and what is an advantage to length ( ll ) vs. ll.length().
Would I need to pass this method anywhere (rare case IMO) I could use an
adaptor.
Infix syntax: I do not think this feature useful enough to justify weird
syntax. Most probably it wouldn't be use for anything other then several
functors like plus, minus.
Documentation
-------------------------------------------------------------------------
There two major problems I have with docs: first they are very scarce on
design of the component described and second they are written for Haskell
programmer who is learning C++. I believe that at least 90% of C++
practitioners never heard about Haskell. Accordingly it should not be
mention in docs AT ALL. The should not be ANY references to Haskell syntax,
which instead of clarifying things make it worse and left me with feeling
that I did not get something. There should be a short introduction to what
is a functional programming paradigm. Comparison with existent C++
paradigms, advantages and disadvantages. I don't say it should be extensive
multipage work, but just an introduction for C++ programmer not familiar
with FP.
There should be reference documentation for any functor supplied by the
library. I am not sure there is a need for old (pre boost) references in
docs. It absolutely unnecessary for new users. Why existent users may use
some kind of transition guide in FC++ website.
The rest of docs looks in most part as a "simple overview", while I expect
to see a real full documentation.
Implementation
-------------------------------------------------------------------------
0. It would be much easier if you would follow recommended boost directory
structure
1. BOOST_FCPP_DEFER_DEFINITIONS
This does not look like a good solution. What exactly did you try to
achieve?
2. definition.cpp
What is this? Does it gets compiled by any compiler?
3. All implementations needs to be rewritten using Boost PP to be extendable
to more then 3 arguments.
4. Why fullN does not inherit from it's parameter, but keep it as a member
instead?
5 What is konst vs. const?
6. When you will eliminate implicit currying implementation became more
simple
7. binderNandK...ofM facility does not look extendable. Did you look how
boost::bind is implemented?
8. There are still a lot of identifiers that does not follow recommended
boost naming policy
9. Why infix syntax implementation is mixed with some library supplied
functors?
Testing/Examples
-------------------------------------------------------------------------
There is a lot of staff in fcpp_clients directory. Since there is no
test/examples separation and no Jamfiles I couldn't comment in details how
it looks.
Regards,
Gennadiy.
