Re: [boost] typelists: MPL tutorial + partial review

From: David A. Greene (greened_at_[hidden])
Date: 2001-12-11 18:12:07

David Abrahams wrote:

>>greatly.  Still, a looping construct to generate trees seems
>>a little "out of place."
> 
> While it's technically a tree, the algorithm to build it is entirely linear.
> There's nothing "tree-like" about GenScatterHierarchy, really.

Which GenScatterHierarchy are you talking about?  I was
referring to Loki's implementation.  It's recursive in
that it uses inheritance directly, "slicing off" members
of the typelist.  Not having looked at the MPL for_each
implementation, I assume it does much the same thing.  But

this sort of typelist manipulation to me fits more naturally 

in the context of inheritance than in iteration.  Perhaps I'm
just too biased by a particular typelist implementation.

>>For me, recursion is just much more
>>natural.  Perhaps this isn't true for most.
> 
> What happened to me was that as the metafunction (which sometimes has an
> associated runtime function) became more complex, just getting all of the
> right pieces into the terminator of the recursion became difficult.
> Sometimes it was a big advantage to be able to break out the expression for
> termination into a separate meta-expression (e.g. with find_if).

I can see your point here.  I'm not arguing the for_each
should be eliminated.  I don't have the experience or
authority to say that.  But simple things should be
simple, and GenScatterHierarchy as presented by Mat is
not.  Your version was clearer, but did require the
aggregation of several meatfunctions into one class.

>> > I find the analogy between the use of the STL and the use of MPL makes
>> > things much easier.
>>
>>I think it is somewhat deceptive.  The names and arguments look
>>familiar, but the STL algorithms work smoothly because iteration
>>is a natural interface to containers/sequences.
>>
> 
> That's somewhat presumptuous of you. 

What's presumptuous?  I'm sorry if I gave offense, that
was certainly not my intention.  If I've got something
wrong, please correct me.  I'm learning, so forgive an
intermediate-level Boost newbie.

> metafunctions. I kept going back to MPL because it really did save thought
> cycles. The metaprogramming problems I was solving were hard, and having
> some prepackaged algorithms and an idiom to work in was a big help. It was
> worth the (not insignificant) investment to learn how to use it without any
> documentation.

I have not once argued that some MPL constructs aren't useful.
What I argued was that their use for GenScatterHeirarchy was
more confusing than equivalent Loki code.  I'm arguing that
a framework to allow recursive algorithms should be included.

> 1. Someone defined a framework of concepts through which many problems could
> be understood and decomposed
> 2. They provided a suite of useful basic components

Of course.  MPL provides that.  Loki provides another.  I
just happen to think that some problems map better onto
recursion than iteration.

>>I suppose one
>>could argue that a typelist is just another sequence,
>>which it certainly is, but due to the limited interface we 

>>have for C++ metaprogramming (no vararg templates, etc.), 

>>recursion is a natural way to represent them.
> 
> Just like list or (if you have it) slist. Even lisp programmers all know you
> can use "pure recursive" programming, but they also have for_each, find_if,
> lambda.... Often these are implemented with recursion under-the-hood, just
> like MPL algorithms.

Right!  Keep for_each!  I'm just asking for more options.

>>The simple observation that (partial) specialization is used to 

>>provide a terminator/sentinel points to the natural use of 

>>recursion in metaprogramming.
> 
> I don't understand that argument.

Just as recursive functions have a termination condition,
recursive metaprograms have a termination specialization.

I think about runtime recursion as a tree, where the leaves
are the bits of code recognizing the termination condition.
Metaprograms map nicely onto this model where the
specializations are at the leaves.

> The associative containers have no more got a recursive 

> structure than std::list does. 

When I think of "list" I think "linear."  Of course it _can_
be represented recursively.

> What they have is a tree structure. 

Which is a recursive structure.  Child nodes are trees.

With my poor analogy I was trying to point out that
straight iteration from start to finish isn't
always the best solution, even though it might
get the right answer.

> It's not a pity that they're not implemented with recursion; 

> a recursive implementation would be slow.

That was my weak attempt at subtle humor.  :)

Please, I don't mean to take away from the work that's
been done on MPL.  I don't wish to participate in a
flamewar.  I just wanted to present first impressions
from a relatively new Boost user.  Perhaps that's not
useful because I don't have enough experience with
Boost or metaprogramming.

                                 -Dave

-- 
"Some little people have music in them, but Fats, he was all music,
  and you know how big he was."  --  James P. Johnson