This is a comment actually to all three "factoid" related parts of the library. I am not very familiar with functional programming terminology and paradigms. And I do not like inventing new word without substantial reason. So here is my understanding on what this part of the library all about and my thoughts on what shout be done. Please point if it is simply silly and ignorant. C++ standard introduces and STL uses notion of function object a generic abstraction for function. By design it is structure type with non-template operator(), where types of the arguments and result types are unambiguously defined by the type of function object (it could be hardcoded types or types dependent on structure template parameters). So let's call it monomorphic function object, opposed to the alternative design for function object, which uses member template operator() which we will call polymorphic function object. Polymorphic function objects in some ways better/more powerful than monomorphic ones. But there is an issue of result type deduction, which require special support. Solution is described in mention by you paper and your library implements it (as I understand it). Now the question is why would we need separate notion of functoid, while we already have powerful abstraction for function objects presented by boost::function? Why boost function does not present this functionality (if it does not, I am not sure)? This looks like obvious place to implement this solution: you provide helper facilities to make it easier to write polymorphic function objects and you make boost::function polymorphic function object aware (even though it still be a model for monomorphic function object). This will cover indirect functoids also. (BTW why do you need virtual for it's implementation - I did not see single one in boost::function) Currying: I have a question: why boost::function does not provide currying internally? Why do we need boost::bind? IMO polymorphic function object currying should be incorporated in boost::bind. The same applies to lambda facility. Smartness: I believe boost::function interface may be extended a little if we find your addition convenient. But as for now arity seems to be good enough. Infix syntax: I am not sure I like the idea in a first place. But it could be discussed and added Also it's my understanding that library provide corresponding polymorphic counterparts to STL functors defined in <functional>. I believe we do need to do so, in boost/functional.hpp. Regards, Gennadiy.