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

From: Ron Garcia (garcia_at_[hidden])
Date: 2002-07-20 13:16:05

Aleksey Gurtovoy wrote:

>Ron Garcia wrote:
>  
>
>>- 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?
>  
>
I think "metafunctions" is adequate, but "metafunction classes" seems 
fine as well.

>>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 :).
>  
>
If I catch any specifics in more recent editions, I will report them.

>>Test Cases:
>>- No Test Cases For:
>>
>>    
>>
>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'.
>
>  
>
That rationale makes sense to me.  Could this be noted somewhere in the 
reference docs? maybe an entry in the index, "accumulate: see fold" 
would be good as well (OTOH, I don't know how many folks actually use 
STL religiously enough to be confused by this).

>>- '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.
>  
>
Nothing significantly better and similarly succint as well comes to 
mind.  If I come up with any quality suggestions, I will let you know.

A question:  

Will all  features of the library be available for all of the tested 
compilers, or are there more and less portable uses of the library.  If 
there are differences between compiler acceptance, could those be 
documented in one place?

>  
>
>Thank you for your feedback,
>
>  
>

cheers,

ron