Re: [boost] Submission: typelist

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2001-11-27 19:13:32

From: "David Abrahams" <david.abrahams_at_[hidden]>
> From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
> To be fair, Andrei, you should compare a version of Loki typelists that
> works without partial specialization.

Maybe, but I don't think so. Mpl's whole design is like that. I prefer to
have a good, simple design that uses partial specialization and then hack to
it to port it to today's MSVC, rather than putting in place a very
complicated design that brings no extra power.

> I had hoped that when Aleksey and I "discovered" that map/accumulate
seemed
> to be /the/ fundamental iteration algorithm,

... here a LISPer would say "but we discovered this in the early 1960's"
:o).

> In my experience writing some pretty heavy metaprograms, it was certainly
> the case that for simple jobs a recursive formulation made the most sense.
> When things got more complicated, on the other hand, the cost of writing
> specializations to deal with termination conditions began to grow. Once I
> was doing things of a certain complexity, the specializations required for
a
> hand-written algorithm started to badly hurt readability. It made an
> enormous difference to be able to rely on pre-packaged algorithms which
> capture easily understood semantics, and to be able to use simple
modifiers
> like composition, etc.

I'd appreciate pointers to examples. I gave plenty of examples on the
simplicity and usefulness of Loki's typelists. Again, I find the
"pre-packaged algorithms which capture easily understood semantics" as
impenetrable as to be useless.

> Our challenge is to provide a library which makes complicated things
simpler
> and simple things really simple. I don't think MPL is there yet. I don't
> know about Loki.

The loki::typelist code should be eloquent enough; if we are to compare mpl
with Loki, knowing about both would be mandatory. My opinion is not only
that MPL is not there yet, but that it didn't really take the right way.

> > in particular, I didn't find new things that one can do with mpl but
> > can't do with Loki's typelists - although I could be wrong here.
>
> I never understood how to measure that, anyway: anything you can do with
> C++, you can do (theoretically) with assembler. The real difference is in
> expressiveness.

Sure. I'm not sure how this appies to what I was discussing. I made the
point that Loki's typelist is much simpler. Then I made the point that it is
also just as powerful.

> Oh, BTW, the cliff wasn't too bad when
> I was just /using/ the algorithms. Trying to read them could sometimes be
> painful, though.

I don't know, but quite frankly I couldn't say with a straight face that
mpl::at (which does use some algorithms) is simple.

Let me state again a simple point, which I think was underestimated. I just
expressed my opinions here; I don't pretend to be in the possession of the
right way of doing things or whatever. In my previous post I just tried to
present, with objective arguments, why I prefer loki's typelists with
boost's typelist.

On to the addendum:

> It may in fact be that there's nothing to be gained from collaboration
here.

I believe otherwise, but of course I respect others' opinions.

> Nonetheless my impression is that you have reacted with such antagonism to
> mpl's complexity that you have not been able to think carefully about what
> could be learned/used from it.

I thought I'm on record for promoting usage of less-known C++ features in
novel ways, sigh. Anyway... it's not about mpl's complexity, it's about the
fact that it added complexity without enough benefit to sustain that
complexity.

> I would still like to see you engage in a
> productive conversation about that.

But that was exactly what I was doing. My previous post stated that I would
like to keep the typelist submission as it is, and I also gave objective
reasons on why I would like to do that. What does that "still" has to do
with anything? Is it like I've _already_ been uncooperative, or what? If
"engaging in a productive conversation" really means "integrating with mpl",
I provided reasonable arguments on why I think that's not a good idea. I
expect reasonable arguments on why others think it's a good idea.

Andrei