Re: [boost] Re: MPL containers and algorithms

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-08-12 17:06:36

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

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

No, you *have* to provide the iterators every time.  That is implementation
intrusive.  Not that I really care, but it implies manual adaption to any other
previously defined sequence type.

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

Yes.

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

At the same time, alogorithms are pointless without datasets.

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

Exactly.  The MPL does indeed conform to that philosophy, and that is not what I
am arguing about.  I am saying that the reasons for such a generalization don't
apply to functional metaprogramming.  Not that it can't be done, or that it
can't be done well.

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

You can also throw 90% of the possible runtime sequence types out the window
since they don't apply to compile-time in any fashion.  IO, for example.  Also,
a compile-time random number generator is *impossible* without changing the seed
with every compile.  Best you could do is define it as a macro on the command
line, otherwise you would get the exact same result every time since there are
no external influences at all.

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

I am not saying absolutely that it is invalid.  I am simply saying that there
are red flags and that we are paying a price for generality that very well may
not be needed.  In my opinion, that makes the library, at this point,
experimental rather than practical.  Currently, I see no real use for that
generality.  Even if there were a couple different valid sequence types (maybe a
vector (or typelist) and a map), I still don't think that would validate the
full generality that the library uses.  It is easy to define a sequence
converter if necessary.

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

It is better because 1) it implies less template instantiation, 2) is a simpler
implementation to maintain and use, 3) isn't overly generic for no reason.

Look, all I've been asking for is a single example that illustrates one thing
being better than another *and* vice-versa.  I know full well that at this point
things aren't going to change.  And, obviously, only time will tell.  Generality
for the sake of generality is a waste of time (practically speaking, it is
intellectually interesting).

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

Okay, I agree with that. :)

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

I am by no means advocating axing the MPL.  However, I would like to see a
simple subset that *is* proven and practical right now which experimental
libraries such as the MPL could be built on top of.  We already have that
partially in the form of the type traits library.

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

There are many libraries that are overly difficult to use because of the
plethora of 'options' that they have.  These libraries just don't tend to
because massively mainstream.  Why don't we, as C++ programmers, make every
single class and function a fully parametizable template in all of the code that
we write?  Because doing so when only one set of 'parametizations' actually
apply to the problem that is being solved is a waste of time.  It would be
overly generic for no reason.

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

I am not saying that it is *too* powerful.  I'm saying that it is unnecessarily
generic.

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

So is Loki.  So what?  (BTW, I'm not proposing that Loki is the
end-all-and-be-all).  Loki uses a significantly simpler form and has been proven
to be popular.

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

Andrei does, and he *has* been countering those claims.

> If there be such a
> person, step forward and offer your MPL-lite. ;)
>
> Dave

Paul Mensonides