[boost] Re: MPL containers and algorithms

From: David B. Held (dheld_at_[hidden])
Date: 2002-08-12 15:34:16

"Paul Mensonides" <pmenso57_at_[hidden]> wrote in message
news:000901c2419b$f5e9c5f0$7772e50c_at_c161550a...
> [...]
> 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 what way will these modifications of the type sequences and MPL
algorithms be needed?  Or are you just offering YAWIS (Yet Another
What-If Scenario ;)?

> [...]
> 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'm not that challenged by functional programming.  I think it has a
beautiful elegance that makes certain kinds of problems rather natural
to solve.  It really is that *metaprogramming* is harder to think about
than either generic programming or functional programming.  I'll write
Lisp code any day, but trying to determine when to pass _, _1, or _2
to a metafunction makes my head hurt!  And I don't think it's a failure
of MPL, either.  I think it's that the idea of a "compile time program"
is so foreign to conventional programming that it takes a while to build
the experience and intuition to make this a natural way of thinking.
Naturally, it is easier to write metaprograms in functional languages
than imperative ones, but it is just as easy to write non-metaprograms
in functional languages as it is to write C-style code in C++.  FP may
make metaprogramming syntactically simpler, but metaprogramming
itself is still a paradigm shift for most programmers.

> [...]
> By the STL concept, I mean containers-iterators-algorithms, not all the
> little function objects, etc..

I would say the STL is all about algorithms, and iterators and containers
just facilitate that goal.  I've seen comments by Stepanov that seem to
imply that more or less, anyway.

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

The philosophy of the STL, as far as I can see is this: "Algorithms can
operate on any type that conforms to a set of suitable concepts.  By
making the algorithm implementation independent of the source of the
data, we avoid having to re-write the algorithm for each data source."

The philosophy of the MPL, as far as I can see is this: "Meta-algorithms
can operate on any metatype that conforms to a set of suitable concepts.
By making the meta-algorithm implementation independent of the source
of the meta-data, we avoid having to rewrite the meta-algorithm for each
meta-data source."

In the STL, the philosophy is realized by the use of the Iterator concept,
which abstracts the important features of data sequences.  This allows
me to call sort() on a vector, a map, an istream, or the output of an RNG.

In the MPL, the philosophy is realized by the use of the MetaIterator
concept, which abstracts the important features of meta-data sequences.
This allows me to call sort() on a vector, a list, a range_c, a Loki
typelist,
or a custom meta-iterator that I'm not clever enough to finish writing. ;)

I guess I just don't know what would convince you that the STL/MPL
comparison is valid.

> That has been done for many of the abstractions in the STL, but it
> hasn't been done for sequences.

I don't get it.  An STL algorithm takes one or more iterators as
arguments. An MPL algorithm takes a sequence as an argument (just
a pair of iterators, like some people insist should be done for the STL ;).
You are telling me that it should take an mpl::vector or mpl::list as an
argument instead?  Would you care to explain why this is *better* than
the sequence abstraction?

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

I agree.  They would.  Which is why I feel like debating the merits of MPL
is like debating the validity of Superstring theory.  We don't have any
really good experiments to validate (or *invalidate*!) either.  I'm afraid
it
comes down to a lot of intuition, anecdotal evidence, and good ol'
fashioned rhetoric.  I guess I feel that we would have taken a step back
if we said: "Let's axe MPL, and create a nifty subset that doesn't contain
any features that fail to be motivated by a real-world usage."  In the end,
it seems inevitable that one-by-one, those dropped features would
creep back in, and we would end up with the original MPL, years later,
after we gained the experience to see how valuable the original design
was.

Part of the problem is that there isn't really any other artifact in
programming that I can think of that compares to this situation: An
allegedly over-engineered library that offers so much power that people
insist it be scaled down.  I've seen libraries that suffer from feature
bloat, where users demand features that get added without end.  I've
seen libraries that didn't have enough forethought to take into account
future direction, and where changes ended up as a patchwork of hacks.
But I've never once seen a library where the users insist that it is just
too powerful, and should be scaled down.  If it were just a concept in
someone's mind, and the possibility of actually building such an
ambitious library were suspect, then that objection would seem quite
reasonable.  However, the MPL is *here*, *now*, and it *works*.  And
that fact alone has to count for something.

What I think would be a compelling argument *against* MPL is if
someone were to subset MPL in a way that offers all the size/speed
advantages touted by the KISS crowd, and show that such a library
is indeed better.  However, such a subset has been just as scarce
to find as motivating reasons for MPL.  Hasn't Alexsey himself said
that he tried to create a slimmed down library originally, and was led
to the current design after much experimentation?  Who else has the
library writing experience to counter his claims?  If there be such a
person, step forward and offer your MPL-lite. ;)

Dave