Full Functoids Full functoids are "wrappers" that add various capabilities to basic functoids. The capabilities added are - currying (partial application) - infix call syntax (x ^f^ y) - lambda awareness (ability to call with [] or % to delay evaluation) - smartness (knowing the arity of the underlying functoid) - result_of (converting FC++ sig information to result_of info) These capabilities are orthogonal to one another (they are all "wrapped up" in the fullN classes merely as a "convenient" way to add all the features at once). In principle, these wrappers could be applied to any function-object that supports return-type deduction--not just FC++ functoids. In practice, however, a number of issues arise: - currying: If the wrapped functoid takes non-const reference parameters, then currying won't work. I think the current implementation would try to create a "reference to a reference". Apart from this implementation issue, currying with reference parameters creates object-lifetime issues if the curried function object outlives the captured reference. Little messes like this are one of the reasons FC++ tries to stick with "pure" (effect-free) interfaces. - lambda awareness: While any function object could be wrapped to support our f[args] "delayed call" syntax, the result would be an FC++ lambda expression, which is only useful in the context of an FC++ lambda. - smartness: FC++ has a totally different view of "arity" compared to, say, boost::lambda. (See http://www.boost.org/libs/lambda/doc/ar01s05.html#sect:placeholders for some discussion about boost::lambda.) This isn't an inherent problem, but it could cause confusion owing to the different designs. - result_of: This feature only makes sense for FC++ functoids (as it converts our sigs into result_of information). Also, while none of the rest of the library depends on these features in principle, in practice the implementation of many functoids implicitly expect a number of these features to be there (especially currying). As a result, the rest of the library has a strong implementation dependency on full functoids. In my opinion, the syntax sugars provided by full functoids are very valuable; it's no fun to do functional programming when you have to use huge syntax to do simple things like currying. -- -Brian McNamara (lorgon@cc.gatech.edu)