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