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

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-04-11 11:01:48

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

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.

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

        Doug