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

From: Ron Garcia (garcia_at_[hidden])
Date: 2002-07-31 22:39:52

The following is my formal review of the Template Metaprogramming 
Library.  I vote Yes, that the MPL be accepted into boost.  I base my 
results on reading through the reference documentation, reading the MPL 
paper, trying several examples, and replacing metaprogramming constructs 
I have used elsewhere with MPL components.  

I tend not to delve too deeply into template metaprogramming.  As a 
result, I find that MPL's simpler components, such as if_, if_c, and 
apply_if meet the majority of my needs.  Introducing a central and 
publicly visible set of relatively routine metaprogramming constructs to 
boost is a boon in and of itself.  Compile time ifs, etc. located in 
various detail namespaces can hopefully be deprecated and replaced with 
MPL analogues.  In my personal experience, replacing my own 
metaprogramming code with MPL constructs has led to somewhat shorter 
code that better expresses my intent.  The first side effect is nice, 
but the second I find more important.

A great aspect of the MPL IMHO is that the algorithms are factored into 
separate headers.  As a result, one need not import a large header 
library to use one metaprogramming construct.  

As discussed throughout this review period, the documentation is still a 
work in progress.  Reference pages need to be completed for all library 
components, and more tutorial material needs to be made available.  In 
addition, more thorough test cases need to be added to the library test 
suite.  I believe that the current documentation will be a solid 
framework that can be filled in during the coming weeks.  Aleksey has 
made a concerted effort to update the documentation, add missing pages, 
which suggests to me that the MPL reference documentation in the least 
will reach completion soon.  I have seen testing strategies for the MPL 
discussed and I hope to see results in that regard soon as well.

Some discussion has ensued regarding terminology, such as "metafunction 
class" vs. "quoted metafunction" vs. "metafunctor."  My personal 
favorite is the last, metafunctor, due to the analogy to STL functors. 
 Since this library covers new ground and not one of the above 
possibilities is clearly superior, I presume that Aleksey will follow 
his personal taste and that users will eventually catch on to the 
terminology.

With respect to a need for multiple sequence types (vectors, lists, 
etc.) and an STL-like design, I am not yet convinced that such a model 
is necessary for a metaprogramming library.  Perhaps in the near future 
performance numbers will be posted for different compilers and some 
light brought upon the topic.  In the meantime, the MPL provides an 
interesting platform for exploration.  Andrei and others have raised 
interesting and important questions about how metaprogramming can best 
be pursued and what real-world advantages MPL will bring to the table 
compared to previous work on metaprogramming libraries.  I believe that 
time and experience will supply some answers to their questions, and I 
do not find their worries ample reason to prevent adding MPL to Boost. 
 Rather, I think it offers a grand opportunity for some adventurous folk 
to seek the answers to these important questions.

Ron