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

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

----- Original Message ----- 
From: "Aleksey Gurtovoy" :

> Joel de Guzman wrote:
> > > The above implementation is useless for 'tiny_list' (and any type
> sequence
> > > we use here at work).
> >
> > This emphasizes my point. Writing an algorithm in MPL is not as
> > straightforward. It relies on intimate knowledge of some basic
> > infrastructure to do well. On the other hand, STL relies almost
> > solely on "first principles only".
> 
> MPL relies on "first principles only" as well. One of them is spelled "Use
> iterators to decouple the algorithms from particular sequence
> representation". Sounds familiar, doesn't it? :)

But how do you iterate in the first place? MPL iteration is not a
pure abstract concept. You need some MPL infrastructure to
do this correctly. 

For example, if I write an STL for_each, I do not have to use (#include)
any library code at all. The corresponding MPL version includes 7
mpl specific header files. The point here is that with STL, iteration is
supported by the language, with MPL, iteration is supported by the
library.

> > Now this is is not a bad thing, considering the power MPL gives.
> > And considering too that the C++ template metaprocessor was not
> > designed as an FP language.
> >
> > However, extra effort must be provided by the MPL author(s) to make
> > writing MPL algorithms as user friendly as possible.
> 
> That was one of the goals of the library. Most of custom algorithms (and, in
> fact, most of the algorithms MPL offers out-of-box) can be (and are)
> implemented in terms of what we call "the  basic iteration algorithm" -
> 'iter_fold_if' (as you've seen it with 'count_if' example). In other words,
> in most cases you don't have to deal with manual sequence iteration at all
> (unless you want to, of course). You just write the core of the algorithm -
> an operation that should be executed on every step through the sequence, and
> then pass that operation to [iter_]fold[_if] to do the rest of the job for
> you.
> 
> > At this point, it seems that the interface to the authoring of MPL
> > algorithms is tied to its implementation.
> 
> I am not quite sure that do you mean by that (but it's certainly not true
> :). Could you clarify, please?

Simply that I cannot write the simplest MPL algorithm, predicate or
function without using MPL facilities. Consider this:

    template <class IteratorT, class FunctionT>
    FunctionT for_each(IteratorT first, IteratorT last, FunctionT func) {
      for ( ; first != last; ++first)
        func(*first);
      return func;
    }

This is a full fledged STL functor based *solely* on STL concepts.
Now rewrite that in MPL using *solely* abstract MPL concepts without 
including anything. You can't because MPL algorithms rely a lot on 
MPL infrastructure.

However, I admit I am wrong in stating that "the authoring of MPL 
algorithms is tied to its implementation". Accept my apologies and 
let me rephrase: "the authoring of MPL algorithms is tied to an 
underlying MPL infrastructure". But I don't see anything wrong with
that. Most libraries are. What I was objecting to was the notion that
authoring MPL algorithms is as straightforward as authoring STL
algorithms. No. Definitely not. You need to learn and use a core
infrastructure first.

Regards,
--Joel