Re: [boost] Submission: typelist

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-11-27 19:59:31

----- Original Message -----
From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>

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

If it were true that the MPL design gives NO extra power, I would agree in a
second. I think, however, that there are certain advantages in the MPL
design. Here are the ones I can think of off the top of my head, in no
particular order:

1. Algorithms can be used with different compile-time sequence structures
and implementations

2. Function composition

3. Argument binding

4. A far-thinking design for metafunctions which will probably allow a
meta-lambda facility

5. Lifts the need for the user to deal explicitly with loopn termination in
a separate piece of code (the specialization).

6. A convenient way to specify type lists without macros

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

...which is the reason for the quotes.

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

I don't have anything I can post here, but maybe I'll send you something
privately.

> Again, I find the
> "pre-packaged algorithms which capture easily understood semantics" as
> impenetrable as to be useless.

If you just look at the examples of how to use them, without looking at
their implementations, are you still having trouble?

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

My opinion is that it got some things right, and some wrong. No sense
throwing out the baby with the bath water.

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

When you speak of Loki's typelist, are you talking about the compile-time
data structure, or the data structure along with a suite of algorithms,
etc.? If the former, I have almost no argument: the typelist in mpl is just
a typelist, aside from a simple declaration syntax. If the latter, then of
course I disagree, as you yourself have pointed out:

"It doesn't take long to realize that mpl implements a whole language that
has iteration (for_loop), values (int_t), comparisons (lt), incrementation
(next), functional composition (compose_f_gxy)"

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

Me neither.

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

I'm sorry, I want to understand what point you are trying to make above.

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

Then we agree!

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

In its current form, agreed.

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

IMO that does not amount to "a productive conversation about what could be
learned/used from mpl".

> What does that "still" has to do with anything?

"Still" means that I haven't yet seen the kind of discussion which I think
would be most useful.'

> Is it like I've _already_ been uncooperative, or what?

I didn't say that you've been uncooperative. All I said was that a
/demonstration/ of cooperativeness tends to promote consensus.

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

It might well be that integrating with mpl is the wrong idea, but I think
that there are probably useful ideas and idioms to draw from it.

-Dave