[boost] Re: MPL containers and algorithms

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-08-10 00:45:01

"Terje Slettebø" <tslettebo_at_[hidden]> wrote in message
news:0b8101c23fe6$5a6bfe10$60fb5dd5_at_pc...
> Ease of understanding is also dependent on what you are used to. It's not
as
> if Loki was easy to read, once I started to learn about that, either. A
more
> fruitful path might be if someone are reasonably fluent in both kinds of
> libraries, to read and write code for various tasks, and see what was
found
> more readable.
>
> 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.

That's a good argument. However, it should be noted that all you really have
to absorb to start using Loki's typelists is this:

template <class H, class T>
struct Typelist
{
    typedef H Head;
    typedef T Tail;
};

Then, you can naturally use C++'s template engine, which supposedly you
already know, to work for you. That's why I'm saying that the dot-typelists
are closest to the way C++'s metaprogramming facilities work. Dot-typelists
have a complexity/benefits ratio that's, in my opinion, unbeatable.

In contrast, MPL puts a whole wrapper over what the compiler really does, in
an attempt, which in my opinion is only partially successful, to emulate
STL's design.

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

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

> > MPL has been out for a while and there still aren't examples that
justify
> > the presence of multiple containers, even from its own authors. I
> > understand that MPL uses STL's design, and many say this is a hallmark,
> but that's
> > not an argument by itself. As said in another post, they use very
> different
> > means and have very different ends. It's art for the sake of the art if
> it's
> > not useful.
>
> 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.

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.

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

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

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