>  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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost