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

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

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

Cheers,
--Joel