On Sun, Feb 29, 2004 at 11:51:28PM -0700, Jonathan Turkanis wrote:
>  Here is my formal review of FC++ -- sorry to wait to the last minute.

Wow, thanks for these extensive comments.  I appreciate the time you
spent and the many concrete pieces of advice for improvement.


A few quick comments:

I like your suggestions about how to generalize the "arity" aspects of
functoids.  A few people have already mentioned using the preprocessor
or mpl or integer-valued template parameters, but your comments have
been more specific and helped give me a better "global" view of how it
should all work, ideally.


>  B)  Rather than having users define direct functoids, then wrapping
>  them in full functoids when they want to take advantage of 'sugar', it
>  should be made easy to define full funtoids, so that all function
>  objects designed for use with FC++ can be expected to be full. (One
>  still needs adapters for foreign function objects, of course.) I think
>  this could be done with macros, e.g.:
>  
>      struct plus {
>         // declare signature.
>         BOOST_FCPP_LAMBDA_SUPPORT(2, plus)
>         int operator() (int, int);
>      };
>  
>  I thought I remembered several reviewers suggesting this, but looking
>  back, I don't see it. Brian's suggestion for allowing non-const
>  reference parameters seems to require different overloads of
>  operator() depending on which parameter types were declared to take
>  non-const references. If this is true, more information might have to
>  be passed to the macro to avoid an explosion of (mostly disabled)
>  overloads.
>  
>  One could still keep 'full' as an implementation detail, of course.

What's the motivation for this change?  I am all for reducing
boilerplate code, but I am unclear is that is the only reason you're
suggesting this, or if there's another reason you want to avoid the
"wrapping" mechanism in the current implementation.  (I like the idea
of "full-ness" being "just another combinator" (make_fullN).)


>  C) The technique for handling signatures of momomorphic and
>  polymorphic funtoids can be unified. [...long discussion elided...]

A while back, I actually experimented down a road very similar to the
one you describe here.  I ultimately rejected this kind of signature
representation, for a number of reasons (I don't recall them all right
now--we can discuss it more off-list if you like).

It has become so rare that monomorphic signatures are ever used/useful
in FC++, that a viable solution to reduce the complexity here is simply
to eliminate monomorphic signatures entirely.


>  Now, instead of writing reuser2<VAR, INV, VAR, T, U, V>, you write
>  reuser2<T, inv<U>, V>. This looks easier to use, understand, and
>  generalize. You might even be able to drop the '2'.

This is a terrific idea (wish I'd thought of it myself :) ).

-- 
-Brian McNamara (lorgon@cc.gatech.edu)
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost