Re: [boost] Re: MPL containers and algorithms

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-08-11 20:02:41

----- Original Message -----
From: "David B. Held" <dheld_at_[hidden]>

> > 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"?

Sequence abstraction.  I have yet to see a practical example that shows that it
has purpose.  I'll that I have seen is a lot of what-if's.

> > [...]
> > 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 order to work with different type sequences from other places, those type
sequences will still need to be modified.  Such a thing is also likely to cause
the modification of the algorithms that go with it--not because it is necessary,
but because it to make them conform with the MPL's STL-like concept.

In such a scenario, it would be easier to map a foreign structure into an MPL
structure than permeate the design of the MPL with "what-if" constructs.

> > 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.

What is the purpose then?  Just as an example that it can be done?

> > > [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 think that it is just that functional programming is so foreign to many C++
programmers.  I certainly had to get used to it as well. :)

> > > 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)?

Not circularity exactly, just logical leaps and assumptions.  The STL concept
can be good or bad depending on the situation and environment to which is
applied.  By the STL concept, I mean containers-iterators-algorithms, not all
the little function objects, etc..  As I've said repeatedly, there are many
things that I like about the MPL.  Some of the abstractions that the STL makes
do apply, others don't IMO.  I didn't see Terje's factorial example, but I did
see his exponentiation example, and I have no problem with that type of
thing--including some of the improvements that Terje suggests.  However, that is
not going to make me unilaterally believe that something is inherently good just
because of abstraction or because it is similar syntactically or conceptually to
something else (namely the STL).  That has to be shown to be valid for the same
reasons that they are valid for the STL.  That has been done for many of the
abstractions in the STL, but it hasn't been done for sequences.

External types from preexisting libraries and code is a good example, but that
comes down to a question of philosophy.  Is it better to be
'backward-compatible' in such a young field?  I'm not so sure that it is, and
sequence conversion algorithms aren't that difficult to implement if a switch
over isn't reasonable.

> > 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.

I do not think that it ever would have existed if it weren't for containers with
different runtime characteristics.  I also don't think that it is "merely an
implementation benefit of its clever design."  I think that it is primarily the
_validity_ of the design, which is, by in large, contrary to OO.

> > 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.

Such as what?  These arguments aren't any good when they boil down to a lot of
"maybe-s", "what-if-s", and "some time down the road-s."  What about something
like:  "I need a custom typelist metatype right now because the MPL doesn't
provide what I need."?  Something like that would help significantly, both
toward your argument and toward the betterment of the MPL in general.

> > 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.

What is the big picture then?  That you can incorporate many different
implementations of exactly the same thing?  I buy the "syntactic sugar" argument
far more than this.

Paul Mensonides