Re: [boost] Re: Adding Loki to Boost (reprise)

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-10 14:12:09

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

> Ok, I'll try to detail my view. (Warning, many "I"s and "me"s ahead,
> again. This is to protect myself for making wrong generalizations.)

I'm going to try to challenge you to rephrase some of this, so we can
get at the technical substance of your objections...

> My
> problem with mpl is that I see it as an abstraction going in the wrong
> direction.
>
> The C++ template engine is a Turing complete, pure functional
> language. In pure functional languages recursion is natural, iteration
> is ab(d)ominable. This is a fact, and I believe anyone would agree
> with that.

I'm sorry, but I think you're confusing facts with judgement. Let's try
for something a little less subjective. Iteration in the classic sense
is, in fact, impossible. There is no such thing as mutable state, so you
can't make a loop counter.

> I personally programmed non-functional languages most of the time, but
> I prefer "nice code" to "non-functional code at all costs".
>
> MPL strives to add non-functional abilities to the template engine.

Not in my view. Just as classic iteration is impossible, you can't build
operations with state on a stateless substrate. Trying to do so would be
fruitless.

> It
> features loops, iterations, iterators, and the such.

Or: it features recursions and (yes) iterators. What is an MPL iterator?
It is a representation of a position within an MPL sequence. That can be
extremely useful, and has nothing to do with functional vs.
non-functional programming. Quoting from our paper on the MPL:

    "Decoupling algorithms from particular sequence implementation s
(through
iterators) allows a metaprogrammer to create her own sequence types and
to
retain the rest of the library at her disposal. For example, you can
define a
tiny list for dealing with sequences of 3 types as follows..."

Being able to define new sequence types for improving build times can be
extremely important. As I'm sure you've learned from people who have
enthusiastically adopted the techniques of MC++D, heavy metaprograming
with recursive list types often pushes compilers to their limit.

> The intellectual
> effort invested in it is impressive. After all, MPL works in a
> language that's completely unfrendly to what MPL wants.

I think you've completely misapprehended the goals of the MPL.

> As much as I am impressed with MPL's intellectual investment, I am
> completely underwhelmed by its approach by large, and in principle. (I
> am sorry, there's nothing personal to MPL's authors. That's how I
> feel.) I would look the same at a package that adds iterations, loops,
> etc. in Haskell. I am much more comfortable with iteration than with
> recursion, but again, in Rome do what the Romans do: Haskell does not
> like loops, and neither does C++'s template engine.

The recursive algorithms of MPL are all based on an approach that should
be familiar to any functional programmer: the fold() function, which
incidentally is also available in Haskell.

> So I ask: why? To what end?

It's a bit rough, but lots of the "why?" is in our paper. You can see a
draft at: http://groups.yahoo.com/group/boost/files/mpl.pdf

> Note that we're not talking about a problem that has no other
> solution. Au contraire, it's about a problem which has a much more
> elegant solution.
>
> Why?
>
> What I think would be reasonable to ask, for example, is a basic "list
> of types" facility, with typical primitives for lists of types:
> append, erase, find, etc. Yet I cannot look at MPL's incarnation of
> these simplest facilities, without shrieking in horror.

The MPL biases its implementation toward ease-of-use rather than
ease-of-implementation. One thing you may be seeing that complicates the
implementation is loop unrolling, for which there is a very good
explanation (see the paper).

> And I imagine
> that the error messages generated by mpl's misuse are really bad, but
> that's a moot point - all template error messages look bad :o).

I think we can afford to leave moot speculation out of the discussion,
as it only serves to add FUD.

> By comparison, Loki's typelists are - to me at least - an example of
> elegance and simplicity. They are just so cool and elegant. And in all
> honesty, I hope I'm not being blurred by the fact that they're
> implemented by myself. I'm proud to show loki's typelists to any
> fellow programmer; I'd be ashamed to show mpl's typelists to even
> expert C++ programmers.

Why? MPL may not meet your design goals, but it's certainly not
badly-engineered and it's nothing to be ashamed of.

> > Is it really possible to create one metaprogramming library that
> addresses
> > the needs of the majority of the people the majority of the time? If
> not,
> > why not? and if so, let's make sure we have it! Even if this turns
> out to be
> > quite a long term aim.
>
> I don't know. What I /feel/ is that MPL simply goes in the wrong
> direction. I don't want iteration and loops in the template engine. It
> is a pure functional language, and in functional languages you recurse
> (recurse = curse again :o)).

Even Haskell provides Mapm_ so that you don't have to. Writing out
recursive traversals is tedious and error-prone. I want to spend my
keystrokes on non-boilerplate code.

> > This is really a plea for some solid constructive criticism of the
> MPL
> > coming out of all this.
>
> I guess all of the above is not very constructive, and I am truly
> sorry about that. The least thing I want to do is to cause more
> discussion in contradictory.
>
> If I believe mpl should be added to boost? One opinion doesn't matter
> much, but if you asked me, I'd say, if many people love it (and I
> believe they don't), of course. If I enjoy it being shoved down my
> throat? Hell no.

This is where things get really un-constructive. Please, let's try to
keep things on an objective level at least a little. Nobody has
suggested shoving anything down your throat. If you really want to have
a cooperative discussion about how to integrate valuable pieces of Loki
into boost, I suggest you'll have to tone down the rhetoric. I can't
imagine building a successful collaboration around this way of thinking.

-Dave