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
> > > 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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk