Brian wrote: [snip]
The FP programmer, being enamored with higher-order functions (HOFs), notices that all these tree functions have a common pattern. Rather than write tons of miscellaneous tree functions, he instead writes one function to do them all:
// using FC++ struct FoldTree { template <class L, class N, class SPT> struct sig : public fun_type<L> {}; template <class L, class N, class T> L operator()( const L& leaf, const N& node, shared_ptr<Tree<T> > t ) const { if( !t ) return leaf; else return node( t->data, (*this)(leaf,node,t->left), (*this)(leaf,node,t->right) ); } }; typedef full3<FoldTree> fold_tree_type; fold_tree_type fold_tree;
[snip]
In this sense, HOFs and iterators (or iterator adapters) are very similar. The FPers will create _functions_ (like fold_tree) to abstract away in order to create generalized algorithms, whereas the OOPers will create _objects_ (like iterators) for the same general ends. Both strategies have the same general flavor, just taken with a different tack.
I think this is a "problem." That most senior C++-ers already do use the Visitor pattern, or an Iterator model, using function objects as callbacks. And, with Boost.Lambda, they can even construct those visitors on-the-fly. I think one has to dive into the (abstract) beauty of catamorphisms in general to see what an FP mindset can bring to the this table of traversal. Perhaps traversal is not the sexiest introductory field to FP, without deeper appreciation of monads and other functorial constructs, since traversal is already handled, conceptually by a C++-programmer - Iterators; seen it, done it...? /David