Boost logo

Boost :

From: joel de guzman (djowel_at_[hidden])
Date: 2002-04-11 17:59:01

----- Original Message -----
From: "Douglas Gregor" :

> On Thursday 11 April 2002 10:17 am, you wrote:
> > 1) Unlike STL's algorithms, writing an MPL algorithm is not as
> > straightforward and there indeed is a core infrastructure that one
> > needs to learn in order to write one. STL is all about algorithms
> > and allowing the client to write custom algorithms is what I really
> > enjoy about its design. If MPL is to truly follow STLs footsteps,
> > such a "guide to the implementation" or should I say "guide to
> > writing MPL algorithms" *should* be equally important as a
> > user guide.
> This is subject to the usual 'familiarity' argument. Writing an STL algorithm
> is only straightforward because the interfaces have been around long enough
> that it is well understood. Even iterators, which are a daunting concept when
> one first learns STL, are made much more understandable because the concept
> of pointers (with pointer arithmetic) is already well-known to C++
> programmers before they ever hear of an 'iterator'.

No, I do not agree. There's a **much** more steeper learning curve
here than with STL. The first time I saw an STL algorithm, it took
just a minute to sink in. I can't say the same when I first saw an MPL

> Also: I'm not really sure that what you're looking for is a guide to the
> implementation. I don't know and don't care how some of STL's algorithms are
> implemented, but I know the concepts they are based on, so I can extend STL.
> MPL needs only good concept descriptions (which will match STL concepts in
> spirit, though not in syntax) to be extensible. Sure, a list of techniques
> used to get your code working on the broken compilers MPL supports would be
> interesting, but it's nowhere near the importance of a user guide and
> reference manual.

If I write a for_each algorithm in STL, I do not even have to include nor
use anything from STL at all. My home-grown for_each is stand alone.
This is not true in the case of MPL. There are core plumbing that I
should be familiar with before I can use MPL sufficiently to write even
the simplest algorithms.

> > > > I see no reason in arguing which set of algorithms is
> > > > better. Both can coexist.
> > >
> > > That's absolutely true. In many cases, they are the same critters by
> > > different names.
> > > In fact, there's no reason to think of them as "separate sets of
> > > algorithms" except that it's what you may already be used to.
> >
> > Indeed. And I'll be overjoyed to have something like that :-)
> > I imagine being able to port some haskell stuff to the C++
> > metacomputer. This is yet another point. There is already an
> > enormous code base out there while STLish MPL has zero.
> >
> > --Joel
> Enormous code base == enormous Haskell code base?
> If so, then we would need to discuss how much impact that should have. Should
> it be considered with the same weight as C++ existing practice? Maybe.
> I think we'd be wise to table this discussion until MPL's documentation
> reaches the point where we can all understand 'the MPL way' fully. The Loki
> typelist vs. MPL typelist fiasco is a clear indication that MPL has been
> judged before it has been understood.

Hey, I'm not judging MPL. IMO, MPL is a marvelous piece of engineering.
I am already posed to use MPL in my projects. I was certainly hoping that
I was injecting some constructive criticisms here. Last year, I was almost
about to embark on a Lisp/Scheme or Haskell like typelist system using
the C++ template metaproccessor. You directed me to this cool library
called MPL. I looked at it, it was awesome.


Boost list run by bdawes at, gregod at, cpdaniel at, john at