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

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2002-07-19 22:42:36

Ron Garcia wrote:
> Some comments (so far), based on the mpl_18_jul_02 archive:
> 
> The MPL paper:
> - Abstract:  What's a function class?  The abstract should avoid 
> ambiguous terminology.

It's not ambiguous, it's unknown :). But in any case it should actually read
as "metafunction classes": "...an extensible compile-time framework of
algorithms, sequences and metafunction classes." Is it better?

> - Occasional grammatical errors throughout the paper.

Those that already have been reported will be fixed in the new revision. All
others need to be pointed out to be fixed :).

> - The use of the lambda placeholder _1 does not express which
> namespace it is located in.  I would like to see at least the first
> example provide a using statement.

Fair enough.

> - The example in 2.3.4 of implementing "largest" using the mpl has a
> bug.  The metafunction call inside "largest" needs an extra 
> '::type' to dereference the typelist iterator to return the max_element's
type.

Yes, considering that this is supposed to be a complete equivalent to the
early ad-hoc implementation. Will fix.

> 
> Reference documentation:
> - Documentation for Trivial_Iterator is missing.

Copying error :(. Fixed in http://www.mywikinet.com/mpl/mpl_19_jul_02.zip.

> - Missing reference documentation:
> # Metafunctions
> apply
> apply_if
> always

Will document.

> copy [incomplete]
> copy_if [incomplete]
> copy_backward
> copy_backward_if

Fixed in July 19 archive.

> erase_all [incomplete]
> erase_if [incomplete]

These are leftovers from the early days. The algorithms were renamed to
"remove" and "remove_if" correspondingly. 

> reverse [incomplete]
> sort [incomplete]
> unique [incomplete]

Will document.

> iter_fold_backward

Fixed in July 19 archive.

> max_element
> pair
> O1_size
> protect
> identity
> size_of
> same_as
> not_same_as
> if_
> if_c
> project1st
> project2nd
> arg
> next [incomplete]
> prior [incomplete]
> 
> 
> # Lambda Facility
> bind
> compose
> lambda
> placeholders
> 
> # Miscellaneous
> alias.hpp
> assert_is_same

Will document.

> sequence tags
> filter_view
> transform_view

Fixed in July 19 archive.

> iterator_range

Will document.

> iterator tags
> iterator_category
> 

Fixed in July 19 archive.

> 
> # Value Types
> bool_c
> int_c
> integral_c
> fixed_c
> rational_c
> void_
> 

Will document.

> Test Cases:
> - No Test Cases For:
> 01_size
> arg(*)
> begin
> end
> clear
> compose
> contains
> filter_view
> fold
> fold_backward
> insert
> insert_range
> iter_fold(**)
> iter_fold_backward
> max_element
> fixed_c
> rational_c
> pair
> pop_back
> prior
> project1st
> project2nd
> push_back
> remove
> remove_if
> select1st
> select2nd
> transform_view
> vector
> vector_c

That's harsh :). Will add.

> Misc:
> - While 'fold' is a synonym for std::accumulate in the functional 
> programming world, why not call it 'accumulate'?  This would 
> better retain the STL analogy argued for by the library documentation. 

I don't have any problems with recovering the 'accumulate' name as a synonym
for 'fold', but, FWIW, 'fold' vs. 'accumulate' issue has been discussed on
this list before, and the consensus was that 'accumulate' has too much of a
numerical flavor for such a general (family of) algorithm(s) as 'fold'.

> - 'iter_fold' seems like it could use a more descriptive name.

Uhm.. I myself kind of like it, but if you have better ideas I am willing to
consider them.

> (*) - are 'arg' and 'arity' implementation details?

'arity' is, 'arg' is a public component.

Thank you for your feedback,
Aleksey