[boost] Re: MPL containers and algorithms

From: David B. Held (dheld_at_[hidden])
Date: 2002-08-11 19:26:39

"Paul Mensonides" <pmenso57_at_[hidden]> wrote in message
news:000b01c2417f$17ad4a80$7772e50c_at_c161550a...
> [...]
> My only real disagreement with the MPL is the abstraction caused
> by the assumption of more than one sequence type being necessary.
>
> [...Terje said...]
> > Well, look deeper: "plus", "minus", "multiplies", "divides", function
> > composition, etc. All parts of STL, as well. MPL resembles STL + BLL.
>
> These things I am not disagreeing with.  Just the assumption that
> more than one sequence type is necessary <period>.
>
> [...and...]
> > This had nothing to do with sequences at all, and that was deliberate.
> > Instead, it showed the power of abstraction in MPL, which lets you
> > use the same algorithm for any type that satisfies the concepts. This
> > is _precisely_ the same way it is in STL.
>
> How many times to I have to reiterate this?  I _do not disagree_ with
> many of the abstractions in the MPL.  I disagree with the supposed
> need of multiple sequence types.

But earlier, you said:

> [...]
> I think that many people are infatuated with the analogy to the STL
> and are thinking that this analogy will prove itself down the road
> (instead of now).

So is it just sequence abstraction, or also algorithm abstraction that
you think are just "a significant amount of implemenation and design
baggage"?

> [...]
> Count me as #4 also.  A good example that demonstrates the utitilty
> of the sequence abstraction in the MPL would be a significant
> argument for it.

I think Dave A's point about the existence of different sequence types
from different libraries is quite compelling.

> In particular, one that shows that vector-like sequences outperform
> cons-style lists *and* vice-versa in different scenarios.

But I still think this is a red herring.

> > [Andrei said...]
> > It's been months.

Metaprogramming is hard stuff to think about. ;)  That's how long it takes
me to understand one metafunction. ;)

> > I've been glad to see that people realized that using the "STL is cool
> > and MPL is like STL, therefore MPL is cool" argument has some
> > subtle circularity.

Well, I don't see any circularity there.  If we said: "STL is cool because
MPL is cool", then you'd have circularity.  And I think the way MPL is
like the STL *is* cool.  In particular, I think Terje's factorial example is
an interesting study, and I'd like to see the equivalent type-independent
implementation that doesn't use any MPL facilities.

> I'd say it isn't subtle at all. :)

Perhaps you'd like to describe the circularity for the slower readers
(like myself)?

> The STL is great based on abstractions around certain runtime
> characteristics of various sequences.

I don't think the STL is great because of containers with different runtime
characteristics.  I think it's great because a sequence can come from a
container, a generator, an external source, or another sequence (as
Dave A astutely points out by mentioning subsequences).  The fact that
you can create sequence containers with different runtime properties
with the STL is merely an implementation benefit of its clever design.

> Do those same reasons that the STL is great apply to template
> metaprogramming,

Yes.

> and, more specifically, to the use of multiple sequence types?

Yes.  Maybe not multiple sequence types within MPL itself; but then, I
see the multiple sequence types in MPL as syntactic candy offered by
a clever implementation (and proof that the meta-algorithms are truly
generic).  It gives you confidence that using an MPL meta-algorithm
with a Loki typelist is possible and practical.  If, for some reason, I
feel the need to create a custom typelist metatype, where am I to turn
when writing common algorithms with which it can operate?  So far,
just MPL.  Why wouldn't one of the stock typelists suffice?  Perhaps
my application takes advantage of additional information in the
custom typelist.

> IMO, the correlation to the STL breaks down at this point.

That's because you're still stuck on vector vs. list, which isn't the big
picture, IMO.

Dave