[boost] FC++: full functoids

From: Brian McNamara (lorgon_at_[hidden])
Date: 2004-02-17 19:24:59

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_at_[hidden])