Given those definitions, function objects can be generally classified along 3 different axes: - they can be monomorphic or they can be polymoprhic - they can be adaptable or not - they can be rebindable or not
"Direct functoid" is just the term we use in FC++ to describe adaptable, non-rebindable function objects. "Indirect functoid" is the term for "adaptable, rebindable, monomorphic" function object. boost::function objects are classified just like indirect functoids (adaptable, rebindable, monomorphic).
My goal for the various "functoid" terms is not to introduce new vocabulary, but rather merely to simplify the exposition. Hopefully "standard" terms for these concepts will arise soon (I don't think they have yet). In any case, a "standard" implementation for result-type deduction has already arisen (result_of), and FC++ supports this standard.
(Let me know if I still have not answered/addressed your question.)
I do not think we understand each other. Let me rephrase. My position is that polymorphic function object support does not belong to the library dedicated to "functional programming", even though I propose to update boost/functional.hpp header ;)) (BTW it would really help for the whole library review, if you could provide a little introduction what is a "functional programming" in a first place; how it differ from other programming styles and what is the place of your library in this - I mean what purpose does it serve, what solution does it provide). Also after previous letter I found that you actually provide a lot more "functoids" within the library, then counterparts to the STL functional.hpp function objects. These should go in FC++ specific headers (and I mean headers - one per name).
Infix syntax: I am not sure I like the idea in a first place. But it could be discussed and added
It is more useful when you have "named" operators as in FC++, simply because
x ^plus^ y
is often more readable/natural than
plus( x, y )
It may also be attractive to OO people, who have gotten into the now-fashionable habit of avoiding member functions. Switching from the member notation
Shape s; Point p; if( s.contains(p) ) ...
to the non-member notation
if( contains(s,p) ) ...
loses the subject-verb-object order; using function objects that support infix, however, lets you say
if( s ^contains^ p ) ...
which some people may find attractive.
And some really confusing. Moreover in a user code, above most probably would look like if( s ^ boost::fcpp::contains ^ p ). It may be convenient it you are using a lot of code like this. But since I not see problem domain, I couldn't say how applicable it is to real practice. Also it only look pretty for binary functoids. In any case I believe that if you do find it widely useful and could "prove" that, this should be the feature also implemented by boost::function. Gennadiy.