2. Naming.
A) Many of the public types and functions have obscure names. (There are also problems with the internal names, which I'll discuss under 'implementation'.) I'm willing to accept using strange names if they are standard names from FP; however many of the FC++-specific names are needlessly obscure.
For example, the templates c_fun_type, fun_type and the smart_functoidn family are all helper templates designed to add functionality to a derived class, along the lines of std::unary_function. But the names give no indication what they are supposed to do. I still have no idea what the 'c' stands for in c_fun_type. (I'll suggest in (5) below how to eliminate fun_type and smart_functoidn entirely, and replace c_fun_type with 'adaptable'; I'm just using these as examples.)
'fun' should defintely be 'functoid'. 'full' is almost meaningless; I'd suggest other names, but I think full should be eliminated (see (5)).
I would like to second above concerns, since I forgot to mentioned this in my review. In addition I believe we should strive to keep new names clear and follow existing naming in STL. For example, why ptr_to_fun named with addition _to_, while usual STL counterpart is named ptr_fun? And secondly I believe the fact that this or that function named some way in Haskell should not be driving force in naming of our functors. For example I found name 'take' completely misleading (I prefer first_n). Also functor map should probable be named transform since it's the name for existent STL counterpart e.t.c. Gennadiy