Re: [boost] Re: MPL containers and algorithms

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-08-11 12:02:03

>From: "Paul Mensonides" <pmenso57_at_[hidden]>

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

Of course, this is very subjective.

It's a question whether to use pattern matching, or structures like if-else,
or switch-case.

However, there are other issues with pattern matching, as well, which I went
into later in my reply to that posting, such as only being able to test for
type identity (or value), and not more generic conditions, such as the
mentioned "equal_to<Value,value<Value,0> >".

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

Like I said, this is subjective. Note, I did not say it makes it harder to
read. I said it _may_ make it harder to read, as I'm fully aware of the
subjective issue. I tended to find Loki's typelist code easier to read than
MPL, but have later realized this had much to do with familiarity, as it now
tends to be the other way around, especially for more complex components.
The same goes for writing new components.

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

By all means, learning how it works is useful, too. However, I don't think
we should repeat the mistake that some C++ teachers do, to teach C++ the way
themselves learned it, going the C-first way, if there there turns out to be
a better way of learning it, learning C++ as a high-level language, by
_starting_ with using the library, rather than having that towards the end
of the book, as is often common.

Kevlin Henney has a good article about that, here
(http://www.two-sdg.demon.co.uk/curbralan/papers/TheMiseducationOfC++.pdf).
This new way of teaching C++ is used in "Accelerated C++" to great effect,
and we're using it here (http://www.accu.org/begincpp/public/).

I learned C before C++, too, and I used to think it was the best way. I
don't, anymore. The authors of "Accelerated C++" also have experience with
both ways of teaching it.

The same may go for metaprogramming. I also learned the template
specialisation, pattern-matching way first. Much of what I know about
metaprogramming, especially the practical application of it, I've learned
from "Modern C++ Design". So that certainly has much credit for it.

Similarly, it may be better to learn metaprogramming, by using a library for
it, rather than starting with writing your own components.

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

The same has been said about using C++ as a high-level language, to advacate
for teaching the low-level C details first. However, it has been found that
you _can_ use std::string, the STL, etc. as high-level components, without
having to learn how they actually work.

Yes, you may get some horribly long error messages when using STL, but
surely, you don't advacate for everyone making their own STL, before they
can use it? In other words, having to learn how it all works.

In a similar way, you may run into long error messages, when using MPL. So
what's new?

Yes, if you want to create new components, you need to learn how to do that
in the framework. That goes for both STL and MPL. However, you may use
either of them, with some basic understanding of how it works.

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

As mentioned in the previous posting, the basic difference between the two
is binding time. That's all. The rest is about how it's implemented. For
run-time programming, the means are the run-time constructs, and for
compile-time programming, the means are the compile-time constructs. The
ends may well be the same.

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

Let's be concrete, what in MPL would be an example of what you say here?
That is, expressing something that isn't found in FP, and which would be
different to "traditional" MP.

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

Sequences is just one thing. Combination of metafunctions, lambda (not found
it STL, but found in Boost.Lambda), etc. are also similar.

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

Without considering speed, there's another aspect of vector vs cons-lists
worth considering. At least the way they are implemented in MPL, you can't
have vectors longer than the maximum length (50), without using the
preprocessor, at least. I've tried to have longer vectors, but I got errors
when trying it (on g++ 2.95.3). Have you got longer vectors to work?

In any case, in MPL this means using the preprocessor, which may be quite
expensive, certainly on EDG based compilers.

Cons-lists, on the other hand, have no limit to their length, and don't
require the preprocessor.

Thus, you may have constant access to vectors (possibly to lists, too, if
you make specialisations), but they are of limited length, or requires the
preprocessor, or you may use cons-lists, which may be of any length.

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

What I said above here, shows that there are issues, already, especially if
you were to have only vector, as you suggest.

Regards,

Terje