Representing such a function in C++ is non-trivial. Suppose we try to implement map ourselves, and we call our version mymap. There are two key issues. The first issue is this: if we represent mymap as a template function:

   template <class F, class T>
   ... mymap( F some_func, list<T> some_list ) { ... }

   some_other_func( mymap, ... );  // illegal if mymap is template function

   struct mymap_type {
      template <class F, class T>
      ... operator()( F some_func, list<T> some_list ) const { ... }
   } mymap;

The second issue has to do with the return type. What should the return type of mymap be? It should be a list<U>, where U is the result type of applying an F function to a T object. Since the C++ language lacks a typeof operator, we need to represent the return type information ourselves. By convention, in FC++, we represent the return type of a function using a nested template member struct named sig:

   struct mymap_type {
      template <class F, class L>
      struct sig {
         typedef list< typename F::template sig<
                           typename L::value_type >::result_type >
            result_type;
      };
      ... 
   } mymap;

   typename F::template sig<X>::result_type
   // F::sig<X>::result_type   without the "noise" words

As a result, we could define mymap as

   struct mymap_type {
      template <class F, class L>
      struct sig {
         typedef list< typename F::template sig<
                           typename L::value_type >::result_type >
            result_type;
      };
      template <class F, class T>
      typename sig< F, list<T> >::result_type
      operator()( F some_func, list<T> some_list ) const { ... }
   } mymap;

To simplify naming return types, we have the RT helper. Rather than say

   typename F::template sig<X,Y>::result_type

   typename RT<F,X,Y>::result_type

FC++ was the first C++ library to use this scheme as a general mechanism for representing higher-order polymorphic functions. Since then, a number of other libraries have arisen that all use variations of the same trick to enable return-type deduction.

A relatively new proposal standardizes the return-type deduction methods. It uses conventions and syntax different from FC++. FC++ "full functoids" (Section 7) ensure that functoids are forward-compatible with the new standard. At the same time, the RT type computer makes FC++ code backward compatible with functoids using the extant sig structures. As a result, FC++ interoperates with other libraries like boost::bind.

Now, with all of the explanation out of the way, we can finally show the definition of the mymap functoid (Figure 1). This is an example of a polymorphic direct functoid. It has a sig structure, which is a template over the parameter types which computes the result type, as well as a templated operator() function, which uses the sig to name its own result type. Note that, rather than defining the result_type typedef directly, we can inherit it from the fun_type class.

   struct mymap_type {
      template <class F, class L> struct sig : public fun_type<
         list<typename RT<F,typename L::value_type>::result_type> > {};
      template <class F, class T> 
      typename sig<F, list<T> >::result_type 
      operator()( const F& f, const list<T>& l ) const {
         // code to actually implement mymap() function elided
      }
   } mymap;

The definition of mymap given here is what we call a basic direct functoid. In Section 7, we will show how to promote mymap into a full direct functoid, which adds useful capabilities.

Finally, it should be noted that monomorphic direct functoids can be defined without explicitly coding a sig structure, by inheriting from the c_fun_type template class. For example, here is the definition of a function that increments an integer:

   struct inc_type : public c_fun_type<int,int> {
      int operator()( int x ) const {
         return x+1;
      }
   } inc;

Indirect functoids exhibit subtype-polymorphism (the dynamic polymorphism OO programmers are familiar with). This works in the expected way; indirect functoids are contravariant in their argument types and covariant in their return types. An example makes this clear: suppose there are two inheritance hierachies, one where dog is derived from animal and another where car is derived from vehicle. Then we can say

   fun1<dog*,vehicle*> f = ...; 
   fun1<animal*,car*> g = f;    // ok
   f = g;                       // illegal (type error)

Indirect functoids in FC++ are similar to boost::function objects. There are a few notable differences. First, indirect functoids must always be initialized with a function value (there is no default constructor or the equivalent of a "null" function). Second, indirect functoids have all the FC++ full functoids features (like built-in currying and infix syntax, described in the next section), whereas boost::function objects do not. On the other hand, indirect functoids always pass parameters by const&, whereas boost::function objects can have parameters passed by plain reference, allowing for mutation of arguments to the function object.

As described in Section 4, all full functoids exhibit built-in currying. For example, given a 3-argument full functoid "f", we can call it with any subset of its arguments, either by using underscores as placeholders, or by leaving off trailing arguments. Some examples:

   f(x,y,z)          // normal call
   f(x,_,z)          // yields a new unary functoid (expecting y)
   f(_,y,_)          // yields a new binary functoid (expecting x,z)
   f(x,y)            // yields a new unary functoid (expecting z)
   f(x)              // yields a new binary functoid (expecting y,z)

   thunk3(f,x,y,z)   // yields a new nullary functoid

Binary and ternary full functoids can be called using a special infix syntax. This is syntactic sugar, as some functions "read" better using infix notation:

   plus(2,3)        // normal (prefix) function syntax
   2 ^plus^ 3       // FC++ infix syntax

   f(x,y,z)         // normal (prefix) function syntax
   f(x,y)           // as before: yields a new unary functoid (expecting z)
   x ^f^ y          // FC++ infix syntax (new unary functoid expecting z)

Full functoids are lambda-aware. This means that they can be called with square brackets [] instead of round ones () to create lambda expressions. Lambda is discussed in Section 12.

Full functoids exhibit another feature which we have chosen to label "smartness". Full functoids know how many arguments they can accept; a traits class provides access to this information. If F is a full functoid type, then these values are available at compile-time:

   functoid_traits<F>::template accepts<N>::args
   // A bool which says whether F can accept N arguments
   
   functoid_traits<F>::max_args
   // An int which says what the most arguments F can accept is

   functoid_traits<F>::template ensure_accepts<N>::args()
   // A no-op call that compiles only if F can accept N args

We use a traits class to provide literate error messages (along the lines of [McN&Sma00][Sie&Lum00]) so that some common abuses (like passing an F that is not a full functoid to functoid_traits) are caught within the library and a helpful identifier is injected into the compiler error message.

C++ will eventually have a typeof operator, but in the meantime, the standards committee has come up a stop-gap solution to return-type deduction [ReturnType]. The standard solution will be to use, e.g.,

   result_of<F(X,Y)>::type

FC++ basic functoids use a different convention for defining return-type deduction within the FC++ framework (described in Section 5). However, full functoids implement the standard convention (using result_of) as well. As a result, FC++ full functoids interoperate with other template libraries that require return-type-deduction facilities.

The main interface to the list class is provided by just a few functoids:

   list<int> li;       // empty list (default constructor)
   li = cons(2,li);    // cons adds an element to the front of a list
   li = cons(1,li);    // li is now the list [1,2]
   int x = head(li);   // x is 1, the front element
   li = tail(li);      // li is the list [2] (tail==everything except the head)
   bool b = null(li);  // b is false; null() tests for the empty list
   li = cat(li,li);    // li is now [2,2]; cat() concatenates two lists
   li = NIL;           // li is now empty; NIL is the empty list constant

In order to enable lazy evaluation, the list class has a special constructor which takes a thunk which returns a list. The second argument to cons() or cat() can also be a thunk-returning-a-list, rather than a list. For example, after

   list<int> li = thunk2(cons,2,NIL);
   list<int> li = thunk2(cons,1,li);

First, here is how we would write an eager (non-lazy) version of enum_from(), which goes into an infinite recursion when called. (For simplicity, we define it as a monomorphic functoid that works only on integers.)

   struct my_enum_from_type : public c_fun_type<int,list<int> > {
      list<int> operator()( int x ) const {
         return cons( x, my_enum_from_type()(x+1) );
      }
   } my_enum_from;

   struct my_enum_from_type : public c_fun_type<int,list<int> > {
      list<int> operator()( int x ) const {
         return cons( x, thunk1( my_enum_from_type(), x+1 ) );
      }
   } my_enum_from;

   list<int> li = my_enum_from(1);
   for( int i=0; i<10; ++i ) {
      std::cout << head(li) << std::endl;
      li = tail(li);
   }

The discussion here provides a simple overview of lazy evaluation as implemented in the FC++ list class. We have elided a number of interesting details which can impact the performance of lists, most notably, the existence of the odd_list class and the caching ability of lists. To learn more about these details, the reader is referred to

Lists provide perhaps the most common and convenient way to utilize lazy evaluation; representing a (possibly infinite) stream of data which is computed "on demand" is an oft-used pattern. Nevertheless, any computation can be lazified. The by_need monad (see Section 13 for info about monads) illustrates a more general mechanism for lazifying any computation.

To use the Boost FC++ library, just add the line

   #include "boost/fcpp/prelude.hpp"

Note that, by default, the "lambda" and "monad" portions of the library are not enabled. This is both because some compilers cannot handle the crazy templates there, and also because they slow down compilation a little, even if they're not being used. To enable these portions of the library, say

   #define BOOST_FCPP_ENABLE_LAMBDA

The library comes with dozens of example client files (the .cpp files in the FC++ directory). When in doubt about how to use something, check the client examples, which exhibit coverage of most of the library's features.

There are a few other #define flags worth mentioning. These flags are all disabled by default.

   BOOST_FCPP_DEBUG   
   Throws an exception if you try to take the head() or tail() of 
   an empty list.  By default, these operations just result in 
   undefined behavior.
   
   BOOST_FCPP_LAMBDA_DEBUG
   Turns on various extra compile-time checking and custom error
   messages in lambda code.  This is useful for debugging type errors
   with lambda, but slows down compilation, which is why it is disabled
   by default.

   BOOST_FCPP_SAFE_LIST
   Makes all list destructors iterative, rather than recursive.  If you
   have a really long list, you may blow the stack when the list goes
   out of scope.  Setting this flag ensures against this problem, but
   degrades the overall performance of lists, which is why it is
   disabled by default.  If you just need to safely destroy one
   specific instance of a list, just do
      while(l) l = tail(l);   // iteratively destroys l
   
   BOOST_FCPP_DEFER_DEFINITIONS
   Setting this flag makes all the functoids get declared as "extern"
   variables, but not defined.  You then need to link against a separate
   object file with the definitions.  Use this when you are using FC++
   in mutiple translation units, and you do not want each TU to have its
   own copy of all the functoids.
   
   BOOST_FCPP_ENABLE_LAMBDA
   Turns on the "lambda" and "monad" portions of the library, as
   described above.
   
   BOOST_FCPP_1_3_LIST_IMPL
   BOOST_FCPP_OOI_DEBUG
   Deprecated flags; the first one switches to the old (deprecated) list
   implementation, and the second one turns on various debugging code
   for that implementation.

FC++ defines the following constants:

   _          // placeholder for currying
   empty      // an empty struct (empty tuple)
   NIL        // the empty list (zero of the list_m monad)
   NOTHING    // an empty maybe (zero of the maybe_m monad)

FC++ defines these data types:

   // Useful data types
   list             // for lazy lists
   list_iterator   
   maybe            // represents 1 or 0 elements of some type
   odd_list         // (see Section 9 for details)
   strict_list      // eager (non-lazy) version of "list"
   
   // Utility (see Section 5 and Section 7)
   RT               // Return type computer (e.g.  RT<F,X,Y>::result_type)
   functoid_traits  // for seeing how many arguments a functoid accepts
   c_fun_type       // typedefs for monomorphic functoids
   fun_type         // typedefs for polymorphic functoids
   monomorphic_traits  // for reading argument types from monomorphic functoids
   
   // Miscellaneous
   fullN            // full functoid wrapper classes (Section 7)
   funN             // indirect functoid classes (Section 6)
   fcpp_exception   // used, e.g., when taking head() of an empty list

Here are the basic functions that work on lists.

   head           // first element
   tail           // all but first element
   cons           // add element
   null           // test for empty
   cat            // concatenate
   ==             // compare for equality
   <              // lexicographical ordering

   list_with      // helper for creating small lists
   force          // odd_list-ify       (see Section 9)
   delay          // (even) list-ify    (see Section 9)
   
   list_until( pred, f, x )
      // create a list of [x, f(x), f(f(x)), ...] until pred is true
      // Example:   list_until( greater(_,20), plus(3), 1 )
      // yields     [1,4,7,10,13,16,19]

A great many FC++ functions are borrowed from Haskell. See [Haskell] for their definitions.

   until
   last
   init
   length    // Note: also used to force evaluation of an entire list
   at
   filter
   concat
   foldr
   foldr1
   foldl
   foldl1
   scanr
   scanr1
   scanl
   scanl1
   iterate
   repeat
   map
   take
   drop
   take_while
   drop_while
   replicate
   cycle
   split_at
   span
   break
   flip
   reverse
   all
   any
   elem
   not_elem
   sum
   product
   minimum
   maximum
   zip_with
   zip
   fst
   snd
   unzip
   gcd
   odd
   even
   enum_from
   enum_from_to
   just
   // These approximate the corresponding Haskell functions
   and
   or
   h_curry
   h_uncurry

The following named functoids mimic C++ operators:

   // (T,T) -> T
   plus
   minus
   multiplies
   divides
   modulus
   
   // (T) -> T
   negate
   
   // (T,T) -> bool
   equal
   not_equal
   greater
   less
   greater_equal
   less_equal
   
   // (T,T) -> bool    (where T is convertible to bool)
   logical_and
   logical_or
   logical_not
   
   dereference    // T -> U   (where U has typeof(*T) )
   address_of     // T -> T*
   delete_        // T* -> void

The following operators require extra explanation:

   out_stream
   in_stream
      // These are like operator<<() and operator>>(), but they take a
      // pointer to a stream as the left-hand side.  Examples:
      //    &cout ^out_stream^ x
      //    &cin ^in_stream^ y
      // The indirection is necessary to encapsulate the effects within
      // the library (see Section 8)
   
   dynamic_cast_
      // This is a family of functoids, templatized by the destination
      // type.  Example use:
      //    dynamic_cast_<dog*>()( an_animal_ptr )
      // Note that the functoid
      //    dynamic_cast_<T>()
      // has type
      //    dynamic_cast_x_type<T>::type
   
   constructN
   newN
      // These call constructors.  Like dynamic_cast_ above, they define
      // a family of functoids.  Examples:
      //    construct2<std::pair<int,char> >()( 3, 'c' )
      //    new1<int>()( 3 )
      // Note that, e.g.,
      //    new3<T>()
      // has type
      //    new3_type<T>::type

   const_   // Turns a value into a thunk
      // Ex:   const_(3)  yields a new function "f":  f()=3
   
   konst    // Turns a value into a constant unary function
      // Ex:   konst(3)  yields a new function "f":  f(anything)=3
   
   thunkN   // binds all N arguments of a function into a thunk
      // Ex:   thunk2(plus,1,2) yields a new function: f()=1+2
   
   no_op    // do-nothing thunk
   
   before   // before(f,g)(args) = { f(); return g(args); }
   after    // after(f,g)(args)  = { r = f(args); g(); return r; }
   
   emptify  // throws away a functions result, returning "empty" instead
      // Example use:
      //    length( map( emptify(effectFunctoid), someList ) )
      // applies effectFunctoid to each element of someList, even if
      // effectFunctoid returns void
   
   split_args  // split_args(f)(x,y,z)  means  f(x)(y)(z)
      // This is rarely useful, but occasionally necessary

These are some generally applicable combinators.

   compose     // compose(f,g)(args)  means  f( g(args) )
   
   of          // same as compose, but also works on function pointers
               // Good for infix:   f ^of^ g
   
   thunk_func_to_func
      // thunk_func_to_func(f)(args)  means  f()(args)
      // f is a thunk that returns a functoid; this combinator hides
      // the thunk.  This can be useful to break what would otherwise 
      // be infinite recursion in "letrec" expressions.
   
   duplicate   // duplicate(f)(x)     means  f(x)(x)
   
   ignore      // ignore(f)(x)(args)  means  f(args)

These functions promote non-functoids into functoids.

   make_fullN  // promotes an instance of a basic functoid into a full functoid
   
   stl_to_fun1 // promotes a std:: unary adaptable into a functoid
   stl_to_fun2 // promotes a std:: binary adaptable into a functoid
   
   ptr_to_fun  // converts C++ function/method pointers into functoids
   
   funify      // Converts function pointers into functoids, but is
               // the identity function on functoids.  Use this when
               // you're not sure exactly what "f" is, but you want it
               // to be a functoid.

There are a few other miscellaneous functoids:

   make_pair      // creates a std::pair
   min            // lesser of two args
   max            // greater of two args
   inc            // returns ++x
   dec            // returns --x
   id             // identity function
   
   make_manip     // make_manip(aStream)(aManip) returns the manipulator 
                  // for that stream.  Necessary because names like
                  // "std::endl" are not C++ objects.  Ugh.
                  // Example: make_manip(cout)(endl)

We do not describe the interface to the FC++'s lambda and monad constructs here. See Section 12 and Section 13 for that info.

The main interface to the STL is via iterators in the list class. FC++ lists, like STL containers, have a constructor which takes two iterators deliniating a range, so that the contents of an STL container can be (lazily) copied into a list. For example:

   std::vector<int> v = ...;
   fcpp::list<int> l( v.begin(), v.end() );
   // l is not yet evaulated; still holds iterators into v
   fcpp::length( l );  // force evaluation of entire list
   // now l has a true copy of the elements in v

   for( fcpp::list<int>::iterator i = l.begin(); i != l.end(); ++i )
      cout << *i;      // print each element of list

In addition to fcpp::lists, there is also a class called fcpp::strict_list, which has the same structural interface as list, but does not do lazy evaluation. The library "list" functions work on any datatype which meets the FC++ "ListLike" concept, which includes list, odd_list, and strict_list. For many applications, strict_list may be the preferred datatype to use, as it avoids incurring the costs of lazy evaluation when that feature is not needed.

Monomorphic FC++ (unary or binary) functoids are STL "adaptables". The fcpp::ptr_to_fun() functoid promotes C++ function/method pointers into FC++ full functoids. The stl_to_funN functions turn STL adaptables into functoids.

FC++ is related to a number of Boost libraries.

Here is what it looks like to do lambda in FC++. Figure 2 shows some examples of lambda.

   // declaring lambda variables
   lambda_var<1> X;
   lambda_var<2> Y;
   lambda_var<3> F;
      
   // basic examples
   lambda(X,Y)[ minus[Y,X] ]       // flip(minus)
   lambda(X)[ minus[X,3] ]         // minus(_,3)
      
   // infix syntax
   lambda(X,Y)[ negate[ 3 %multiplies% X ] %plus% Y ]
      
   // let
   lambda(X)[ let[ Y == X %plus% 3,
                   F == minus[2] 
              ].in[ F[Y] ] ]
      
   // if-then-else
   lambda(X)[ if0[ X %less% 10, X, 10 ] ]   // also if1, if2
      
   // letrec
   lambda(X)[ letrec[ F == lambda(Y)[ if1[ Y %equal% 0,
                                           1,
                                           Y %multiplies% F[Y%minus%1] ]
              ].in[ F[X] ] ]    // factorial

Inside lambda, one uses square brackets instead of round ones for postfix functional call. (This works thanks to the lambda-awareness of full functoids, mentioned in Section 7.) Similarly, the percent sign is used instead of the caret for infix function call. Note that the alternate function-call syntaxes inside lambda correspond to the alternate semantics:

   f(x,y)   // execute this call now
   f[x,y]   // bind up this function and its args to call later

   x ^f^ y   means   f(x,y)
   X %f% Y   means   f[X,Y]

Since operator[] takes only one argument in C++, we overload the comma operator to simulate multiple arguments. Occassionally this can cause an early evaluation problem, as seen in the code here:

   // assume f takes 3 integer arguments
   lambda(X)[ f[1,2,X] ]    // oops! comma expression "1,2,X" means "2,X"
   lambda(X)[ f[1][2][X] ]  // ok; use currying to avoid the issue

   // assume g takes no arguments and returns an int
   // lambda(X)[ X %plus% g[] ]   // illegal: g[] doesn't parse
   lambda(X)[ X %plus% g[_*_] ]   // _*_ means "no argument here"

The if-then-else construct deserves discussion, as we provide three versions: if0, if1, and if2. if0 is the typical version, and can be used in most instances. It checks to make sure that its second and third arguments (the "then" branch and the "else" branch) will have the same type when evaluated (and issues a helpful custom error message if they won't). The other two ifs are used for difficult type-inferencing issues that come from letrec. In the factorial example at the end of Figure 2, for example, the "else" branch is too difficult for FC++ to predict the type of, owing to the recursive call to F. This results in if0 generating an error. Thus we have if1 and if2 to deal with situations like these: if1 works like if0, but just assumes the expression's type will be the same as the type of the "then" part, whereas if2 assumes the type is that of the "else" part. In the factorial example, if1 is used, and thus the "then" branch (the int value 1) is used to predict that the type of the whole if1 expression will be int.

Expression templates often yield objects with complex type names, and FC++ lambdas are no different. For example, the C++ type of

   // assume:  LambdaVar<1> X;  LambdaVar<2> Y;
   lambda(X,Y)[ (3 %multiplies% X) %plus% Y ]

   fcpp::Full2<fcpp::fcpp_lambda::Lambda2<fcpp::fcpp_lambda::exp::
   Call<fcpp::fcpp_lambda::exp::Call<fcpp::fcpp_lambda::exp::Value<
   fcpp::Full2<fcpp::impl::XPlus> >,fcpp::fcpp_lambda::exp::CONS<
   fcpp::fcpp_lambda::exp::Call<fcpp::fcpp_lambda::exp::Call<fcpp::
   fcpp_lambda::exp::Value<fcpp::Full2<fcpp::impl::XMultiplies> >,
   fcpp::fcpp_lambda::exp::CONS<fcpp::fcpp_lambda::exp::Value<int>,
   fcpp::fcpp_lambda::exp::NIL> >,fcpp::fcpp_lambda::exp::CONS<fcpp
   ::fcpp_lambda::exp::LambdaVar<1>,fcpp::fcpp_lambda::exp::NIL> >,
   fcpp::fcpp_lambda::exp::NIL> >,fcpp::fcpp_lambda::exp::CONS<fcpp
   ::fcpp_lambda::exp::LambdaVar<2>,fcpp::fcpp_lambda::exp::NIL> >,1,2> >

In the vast majority of cases, the user never needs to name the type of a lambda, since usually the lambda is just being passed off to another template function. Occasionally, however, you want to store a lambda in a temporary variable or return it from a function, and in these cases, you'll need to name its type. For those cases, we have designed the LE type computer, which provides a way to name the type of a lambda expression. In the example above, the type of

   lambda(X,Y)[ (3 %multiplies% X) %plus% Y ]
   // desugared: lambda(X,Y)[ plus[ multiplies[3,X], Y ] ]

   LE< LAM< LV<1>, LV<2>,   CALL<plus_type,
      CALL<multiplies_type,int,LV<1> >, LV<2> > > >::type 

   LE< Translated_LambdaExp >::type

   CALL            [] (function call)
   LV              lambda_var
   IF0,IF1,IF2     if0[],if1[],if2[]
   LAM             lambda()[]
   LET             let[].in[]
   LETREC          letrec[].in[]
   BIND            lambda_var == value

Finally, it should be noted that if the lambda only needs to be used monomorphically, it is far simpler (though potentially less efficient) to just use an indirect functoid:

   // Can name the monomorphic "(int,int)->int" functoid type easily:
   Fun2<int,int,int> f = lambda(X,Y)[ (3 %multiplies% X) %plus% Y ];

Whereas FC++'s lambda and boost::lambda superficially appear to do the same thing, they are actually quite different. FC++'s lambda uses explicit lambda syntax to create a minimal sublanguage with language constructs found in pure functional languages (e.g. letrec). On the other hand, boost::lambda supplies almost the entire C++ language in its lambda, overloading every possible operator in lambda expressions, which can be created implicitly just by using a placeholder variable (like _1) in the midst of an expression. For more discussion about the differences, see [McN&Sma03]. For more info about the lambda library, see [Jär&Pow03] or [Jär&Pow01].

The most obvious limitations have already been mentioned: functoids in FC++ are only supported for up to three arguments, and functoid parameters always have value semantics. In practice so far, the three-argument limit has not been an issue. There are no technical reasons that the framework cannot be extended to accomodate additional arguments if this is deemed valuable.

The choice of "value semantics" arguably requires some justification. Most functional languages are "by value", and indeed in many functional languages, most (if not all) objects are immutable, which makes reference semantics unnecessary. While reference parameters for functoids could be supported by FC++, these would complicate the implementation and provide no extra utility within FC++ (due to the absence of lvalues). Unfortunately, the choice of "value semantics" sometimes makes it hard to interface FC++ to extant C++ code that utilizes references. Simply put, FC++ was not designed with cases like these in mind, and thus (like all tools) FC++ is not the best tool for every job.

Functional programmers who desire a more technical discussion of the limitations of FC++ compared to functional programming languages and type systems should read Section 8 of [McN&Sma to appear]. It should also be noted that FC++ provides no support for the creation of algebraic datatypes or for pattern matching.

FC++ also does not provide any kind of "tuple" datatype. The commonest case, 2-tuples, are adequately met by std::pair. Users wanting a more general tupling mechanism should use boost::tuples.

As mentioned in Section 15, the "lambda" and "monad" portions of the library use expression templates, which can seriously degrade compile-time performance. Clients which make heavy use of lambda and monads take a long time to compile and require a lot of memory. Hopefully, in time, C++ compilers will get better at compiling expression-template code.

Finally, this document could use some improvement. Two things are notably absent: some medium-sized examples demonstrating the utility of the library, and an initial motivating example. One of the challenges of presenting such examples well is choosing the application domain—as described in Section 14, FC++ can be applied to a variety of domains. (If you have suggestions for improvement here, please let Brian know.)

Over time, the FC++ library has grown and evolved a lot in order to meet the needs of its users. Though we consider the bulk of the implementation infrastructure complete, there are still a number of interesting future directions to consider. These include

By all means, if you have feature requests for FC++, contact the authors—especially in cases where you already have a real client application which demonstrates the need.