Re: [boost] Re: MPL containers and algorithms

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-08-13 18:32:45

----- Original Message -----
From: "Terje Slettebø" <tslettebo_at_[hidden]>

> What I would now like to see, is, at least an outline of, an MPL without the
> iterator concept. We could then use that as a basis for discussion. For
> example, what would the interface to sequences, algorithms, etc. be. Without
> this, I think it'll mostly just be the what-if's. We already have the MPL
> example. To put it the way the critics have, I have yet to see a convincing
> alternative to MPL.

What example have we seen of MPL that shows that the underlying concept is
sound?

> To make any comparison easier, tasks to be accomplished, using the two
> approaches, would also be useful.
>
> > The most relevant problem with the example is that it has nothing to do
> with
> > sequences or containers--which is the primary thing that Andrei and I are
> > debating.
>
> Andrei also questions that example, so it was useful in itself.

Andrei questions that example, I think, primarily because of the type
abstraction.  ...and I agree with him on that point.  It makes the algorithm
significantly less complicated an more general purpose.  The relative
super-minority that needs, for some reason, to do floating-point calculations at
compile time can make their own factorial to do it.  <-- which, by the way,
would also be simpler.

> Actually, I understand it wasn't obvious, but apart from using factorial as
> a deliberatly simple example, I also used it because it's useful in it's own
> right. It enables you to for example calculate the trigonometric functions,
> using Taylor series, which was the primary reason I made it in the first
> place. It's useful to have factorial, anyway, though.

I don't necessary think that it's the best way, but I don't really care about
this at all.  The MPL doesn't force you to put together the minor pieces like
this.  The MPL does, on the other hand, force you to use the MPL analogies with
the major pieces.

> > > >Enough of that version.<
> > >
> > > Agreed :o).
> >
> > This is the most amusing email that I've read in days. :)
>
> Perhaps I made it a little too easy for Andrei, here. However, I didn't
> expect such a cheap point to be made from it. Or I would probably not have
> said that. It was my opinion that that version was better, for reasons I've
> shown above here. However, this is something both of you may not have
> considered. Metaprogramming is not limited to integer calculation, or using
> the built-in types, only.

Of course it isn't.  It is a Turing complete language so you can do all sorts of
things.  The question is whether something is best implemented with
meta-programming, runtime programming, or an external generative program.  This
goes into the "ends" that Andrei mentioned, and where metaprogramming is
*useful*, rather than just "can be done."

> Or result in ugly workarounds. Personally, I find having to have a sequence
> converter to be a less elegant solution, than to have a uniform iterator
> interface. For the same reason I would have found it inelegant in STL,
> regardless of efficiency concerns.

There is actually a common need for different sequences at runtime.  Not so with
metaprogramming.  The need for any type of converter would hardly ever be
necessary.

> > We have a massive
> > difference in perspective here IMO, academic vs. practical.
>
> I'm not clear who "we" you are talking about, here. You've expressed
> understanding the usefulness of algorithmic abstraction, as elaborated on
> above. Andrei still questions this. You both question the usefulness of the
> iterator concept.

Andrei and I vs. you (in particular).  Yes, you can do all sorts of things with
metaprogramming--just like you can do all sorts of things with runtime
programming, but that doesn't make something worthwhile just because it can be
done.

> My example above, that Andrei was replying to, is such an example that
> you've said shows useful MPL abstractions. So who are you agreeing with,
> really?

What do you think Loki's "Select" is?  It is the near exact analogue to
apply_if.  Some things are useful in the practical world, some things are
not--abstracting the types is not--in any kind of general sense--useful in the
real world.

> > I agree.  The MPL should be able to stand on its own without the STL
> backing it
> > up.
>
> True. However, much of the reasons for the power of MPL, is the same as the
> reasons for it in STL, the abstract interface, where you're not limited to a
> specific sequence, algorithm, value type, or whatever. This is an open-ended
> framework.

Abstraction by itself is not a good reason for its existance.  Something
actually needs to be abstracted.  There is no sequence analog in the MPL to the
STL at all.  It is just this completely arbitrary assumption that it is useful
at runtime therefore it is useful at compile-time.

> > I'd like to point out also that Loki's typelists are used in real life
> also.
> > Further, idioms implemented with typelists are used in real life, and Loki
> > doesn't have sequence abstraction.
>
> > The argument doesn't fly because bad code is
> > being used all over the place ( not to say that the MPL is bad code for
> what it
> > is supposed to be doing! ).
>
> I was just replying to the question for real-life examples. I didn't say
> that Loki's typelists isn't used in real-life, as well. Indeed, I've used
> them in my own programs. They worked well for that. However, I'm questioning
> the extensibility of that way of doing things.
>
> Furthermore, aren't you contradicting yourself, here? First you make the
> point that Loki's typelists are being used, and then you say the argument
> (about something being used) doesn't fly, as bad code is also being used.
> Sure, but this is not an argument against a specific library. You can't use
> the use of Loki as an argument for Loki, yet deny the same argument for MPL.
> No having your cake and eat it too.

No, I was saying "who cares" to your statement that the MPL is being used--so is
Visual Basic--so what?  What kind of argument is that?

> > The question is, could all of the uses of the MPL
> > in Boost (in the Python lib, etc.) be recreated *without* sequence
> abstraction?
>
> Perhaps much of the current use could. However, there's the question of the
> extensibility in this approach.

I guarantee that all of it could.  Extensibility to what?  Without something
specifically in mind (say an example maybe?), you are going to run into a
situation where the MPL is ill-suited and needs a huge redesign to facilitate
the new "concept."  The problem is not that it can be done, or whether it is
_usable_, the problem is that the design permeates a major portion of the
library for reasons which [might become apparent].  This is a lack of foresight,
not an inspiration.  You create abstraction when you have something that needs
to be abstracted.  Otherwise, you can't possibly predict what the next thing is
going to need.

> As Dave Abrahams replied in a posting, he has experience with a case where
> they picked a typelist, to implement it. However, it may later turn out that
> another sequence was better. If you hardwire it to a specific sequence, then
> it's not possible to do it like this. Then you're stuck with a specific
> performance characteristic, also with respect to compilers.

Where do you get these supposed "characteristics"?  You are just unilaterally
applying runtime concepts to compile-time structures.

> Personally, I
> would oppose a design that didn't let me use it on the system I use, which
> is mostly Intel C++. On this system, vectors are very slow, if they work at
> all.

What kind of sizes are you talking about?

Paul Mensonides