Re: [boost] Re: MPL containers and algorithms

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-08-10 14:43:48

----- Original Message -----
From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
> > I have learned to read Loki's typelist code. Still, I find, when writing
> new
> > algorithms for it, that you tend to get lot of different specialisations,
> > that tend to, well, specialise the code. :) That is, you get a specific
> > solution to something, that may not generalise well. Also, the code tends
> to
> > be spread out, like this, which I think may make it harder to read, than
> if
> > it was in one place.

I don't buy this argument either. :) I don't think that a template partial or
explicit specialization that is right next to the other specializations is hard
to read.  Taking Loki's design as an example, much of Loki could be rewritten to
make it "all in one place" simply by using nested template classes.  This is
totally a preference issue.  One could easily say that the separation of the
code via template specialization makes the code *more* clear (and vice versa, of
course).

[snip]

> > Having learned MPL, as well, I disagree with that it should be harder to
> > learn, harder to use, and the client code harder to understand, than a
> > library like Loki's typelists. It may well be the other way around.
> >
> > Like I said, I think it has much to do with what you're familiar with.
>
> That doesn't, in and of itself, really say anything. Of course what's most
> familar is also easiest. I think that a newcomer, however, can be
> comfortable very soon with using dot-typelists than with an extremely
> complicated incomplete compile-time emulation of the STL.

Also, a newcomer has an easier learning curve to template metaprogramming and
how it works in the general sense--rather than the use of a specific
library--Loki or the MPL.

> > In fact, MPL code resembles more run-time code, than Loki's typelists,
> which
> > means that you can use your experience with such code, when using it.
>
> Agreed.

Agreed as well, _however_ template metaprogramming is a different environment
altogether.  You are simply hiding the natural way that environment works with
constructs that can only imitate imperative programming.  This is not
_completely_ bad, but it does have disadvantages as well.  At some point, a user
is going to run into the full, actual environment that is template
metaprogramming with no analogy to STL to help (i.e. coddle) them along.

> > I think the means and ends are similar.
> >
> > It's not clear to me what the differences would be, could you point me to
> > the posting you refer to, or elaborate?
>
> I was referring to my post that emphasizes (1) that templates offer a
> different computational model than C++'s runtime virtual machine; (2) that
> we use C++ compile-time programming for different tasks than C++ run-time
> programming.

And this is absolutely true.  In fact, the purpose of metaprogramming is to
complement 'regular' programming in some way or another.  That is
metaprogramming's ultimate 'ends'.  For obvious reasons, runtime programming is
not equivalent.  Nor or the means and ends similar--that doesn't make sense. :o)

> Two details: when I say "virtual machine" I mean it in the sense that every
> language describes a virtual machine that executes programs written in it. I
> felt compelled to precise this because the term "virtual machine" has been
> recently used in conjunction with Java's JVM. The other detail is that I
> intentionally mentioned "C++" - as opposed to other languages (such azs
> LISP), where compile-time and run-time programming are really hard to
> distinguish. Truly LISP's macros are sometimes of amazing power exactly
> because they use (almost) the same mechanisms as LISP's runtime virtual
> machine. In passing being said, macros are also one of the reasons for which
> LISP programs are impenetrable but to a handful of gurus.

Plus, counting past 20 parenthesis makes my head hurt. :)

> My opinion is that C++ will never be there, simply because its template
> engine is very different, and much more scarce, than its runtime
> counterpart. That's why MPL seems to me like an interpreter written in awk
> or advanced threading in Visual Basic: wow, look, it can be done, how
> quaint - but man, you just get that feeling that the tool is totally
> inappropriate for the job. That's why I also wouldn't be keen of
> manipulating collections of 10,000 types at compile time in C++.

I don't think that we should be worried about 10,000 element collections right
now anyway.  1) we don't have the tools (i.e. compilers) to deal with it yet 2)
we don't know _absolutely_ if it might even be worthwhile.  We need to cross
that bridge when we come to it.

> > Even if metaprogramming is implemented as functional programming, the
> > implementation shouldn't decide what are, or are not, useful abstractions.
> > If that was the case, then we'd use assembly code, because after all,
> that's
> > how it's implemented.
>
> I don't understand how the above applies to the discussion.

He means, I think, using imperative types of abstractions (such as iteration vs.
recursion, etc.) in a functional environment.  In a sense he is right.  _But_ we
have decades of experience with imperative and functional languages that say one
thing or another is not a _natural_ idiom in a functional language.  We better
be pretty sure of ourselves to throw out the learning gained in the past.

> Anyhow, to me in the present the situation looks like this.
>
> It's been months. 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.

I'd say it isn't subtle at all. :) The STL is great based on abstractions around
certain runtime characteristics of various sequences.  Do those same reasons
that the STL is great apply to template metaprogramming, and, more specifically,
to the use of multiple sequence types?  IMO, the correlation to the STL breaks
down at this point.

> The most fervent MPL sustainers couldn't come with a
> compelling example that justifies MPL's design. MPL's *author* couldn't come
> with a compelling example that justifies MPL's design. So far opionios seem
> to be (1) MPL is the library of 2050 arrived on today's laptops, and it will
> be a matter of time until its vision will be fully understood and
> appreciated (2) it sounds like a really cool intellectual achievement (3) "I
> don't know much so I won't say anything" and (4) a vocal minority, of which
> I am part, who questions some of MPL's design decisions.
>
>
> Andrei

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.  In
particular, one that shows that vector-like sequences outperform cons-style
lists *and* vice-versa in different scenarios.

To be honest, I seriously doubt that anybody *can* come up with a good example.
Personally, I think that the vector-style will always be faster and the
cons-style always more elegant.  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).  This is an experimental viewpoint, not a practical
one.  If it doesn't turn out that way (which could *easily* be the case), we
have brought along a significant amount of implemenation and design baggage.

Paul Mensonides