[boost] Formal Review: Template Metaprogramming Library (MPL)

From: ebf_at_[hidden]
Date: 2002-07-29 02:40:09

Below is my formal review for the Boost MPL Library:

__Library Design__

On the whole, I find MPL to exhibit an astonishingly high 
level of design; from lambda/bind expressions to familiar 
STL-like algorithms, MPL exposes a great amount of power 
through a consistent and highly reusable interface. 
Overally, I applaud Aleksey for his crafting of MPL's 
interface.

One facility sorely missing is an mpl::is_sequence query 
metafunction. The ability to query an arbitrary type T to 
determine whether it is an MPL-compatible sequence will be 
of utmost importance in creating flexible class templates. 
For example, the desired semantics for the under-development 
boost::variant is to allow a simulated variadic template 
parameter list *or* a single MPL-sequence. That is to allow 
both of the following to exist as valid declarations,

  typedef boost::variant<int,double,std::string> my_variant;

or

  typedef mpl::list<int,double,std::string> types;
  typedef boost::variant< types > my_variant;

Such an 'overloaded' interface cannot be implemented without 
a mpl::is_sequence facility. I discussed the inclusion of 
this facility with Aleksey some weeks ago, but I have not 
yet seen its appearance in the library; it is vital, 
however, that it eventually appears.

Finally, I would like to directly address the question of 
sequence-genericity, however, as it seems to be a 
significant sticking point for some members of the Boost 
community. While I have not yet used any sequence-type other 
than mpl::list in my own code (primarily because mpl::vector 
has only become recently available), I feel that MPL's 
genericity in terms of sequence-types is not detrimental for 
the following reasons:

1) Current code demonstrates the value of this genericity:

 * mpl::vector offers features not available via "dot-style" 
(i.e. mpl::list) sequences, such as random-access to 
elements.

 * mpl::range_c enables large sequences of values to be 
represented compactly and efficiently.

 * mpl::filter_view and mpl::transform_view allow for lazy 
evaluation of sequence filter and transformation operations.

2) MPL's genericity does not come at a terrible price to 
those who do not need it. A few "unnecessary" invocations of 
mpl::sequence_tag and algorithm traits templates does not 
seem to me a terrible price to pay for the genericity 
offered by MPL.

__Library Implementation__

(NOTE: I personally used MPL on MSVC7 and GCC 2.95.)

I am *most* impressed that MPL functions with an (almost) 
uniform set of features on compilers ranging from Visual 
C++, GCC, Metrowerks, Borland (?), and Comeau. I know from 
personal experience in template metaprogramming with MSVC 
how difficult and frustrating compiler bugs and workarounds 
can be. That MPL largely encapsulates these workarounds is a 
miracle in itself.

In addition to encapsulating workarounds, MPL is otherwise 
well-implemented -- that is, it works as intended.  While 
its implementation files tend to be complex and difficult to 
read, this is primarily a result of dealing with the 
above-mentioned compiler bugs. I believe that a pure C++98 
implementation of MPL would appear far simpler than the 
current, macro-laden version.

Quite simply, I believe that MPL both is impressive in its 
capability to deal with broken compilers and stands tribute 
to the sorry state of compiler implementations currently on 
the market. All in all, I am glad that MPL deals with these 
compilers so that I don't have to.

__Library Documentation__

MPL's documentation seems to be the shoddiest part of the 
library. This is not to say that it is *bad* -- as that is 
far from being the case -- but I feel the following changes 
should be made.

MPL has a steep learning curve. I have been using various 
version of MPL for the past 6 months, so I am largely past 
this curve, but I fear for new users of the library.
Primarily, I think more examples should be provided in the 
tutorial, paper, and reference documentation. Currently the 
first is limited to simple explanations of mpl::if_ and 
mpl::apply_if, the second to somewhat obscure applications 
of MPL, and the last to near-trivial uses of the various 
algorithms, metafunctions, etc. While I understand that good 
documentation is hard to write, and I therefore understand 
while it has been long in the coming, I think it will be 
important for MPL's ultimate success in Boost.

Please don't mistake MPL's steep learning curve as a sign of 
poor design, however. The STL -- a library to which MPL is 
(intentionally) similar in design -- surely has a steep 
learning curve for new users, yet few will blame the 
difficulty of learning STL on poor design.

---
For those who need to do template metaprogramming, MPL will 
serve invaluable. Before using MPL, I did extensive 
metaprogramming work without it. There is no way I would 
consider going back to my pre-MPL days <g>.
I wholeheartedly vote for formal acceptance of MPL into 
Boost (with the hope that my nits, particularly regarding 
mpl::is_sequence, will be heard and eventually addressed).
Thanks,
Eric Friedman
ebf_at_[hidden]