"Brian McNamara" <lorgon@[...].edu>  wrote in message
news:20040301225139.GA17066@[...]..
>  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.

>  > 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).

Yes, I think that would be interesting.

I don't mean to press too hard for a particular solution -- my example
was just a suggestion . However, I think it does more than just unify
the mono- and poly- morphic cases: it also makes determining the
maximum arity simple, provides a way to record which parameters are
passed by reference, and is more compact.

>  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.

I am all for getting rid of a concept if its not needed. But I think
you're stuck with some form of monomorpism if you want to handle
pointers to functions, pointers to member functions and function
objects from other libraries.

Also, until we can use the 'auto' keyword to capture the type of a
complex lambda expression, using indirect functoids may be the best
choice for storing lambda expressions in many cases. (I appreciate
your work defining a type calculus for lambda expressions, but it's so
complicated that I can't see myself using it routinely.)

Jonathan



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