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

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

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

> Joel de Guzman wrote:
> > Two points:
> >
> > 1) Unlike STL's algorithms, writing an MPL algorithm is not as
> > straightforward
> 
> Why do you think so? Sure, it's different, due to functional flavor of the
> domain, but it is straightforward in MPL terms. For example, here's (a
> little bit simplified) 'count_if' algorithm implementation:

Why don't you think so? That should be obvious:

    template <class IteratorT, class PredicateT>
    typename iterator_traits<IteratorT>::difference_type
    count_if(IteratorT first, IteratorT last, PredicateT pred) {
        typename iterator_traits<IteratorT>::difference_type n = 0;
        for ( ; first != last; ++first)
            if (pred(*first))
                ++n;
        return n;
    }
    
It's not the functional flavor that's of concern here (a count_if function 
in an FP language should be way more straightforward than its
imperative counterpart). 

Simply, "straightforward in STL terms" is more straightforward than
"straightforward in MPL terms".

>     namespace aux {
> 
>     template< typename Predicate >
>     struct next_if
>     {
>         template<
>               typename N
>             , typename T
>             >
>         struct apply
>         {
>             typedef typename select_if<
>                   apply<Predicate,T>::value
>                 , typename next<N>::type
>                 , N
>                 >::type type;
>         };
>     };
> 
>     } // namespace aux
> 
>     template<
>           typename Sequence
>         , typename Predicate
>         >
>     struct count_if
>     {
>         typedef typename fold<
>               Sequence
>             , integral_c<unsigned long, 0>
>             , aux::next_if<Predicate>
>             >::type type;
> 
>         BOOST_STATIC_CONSTANT(unsigned long
>             , value = type::value
>             );
>     };
> 
> > and there indeed is a core infrastructure that one
> > needs to learn in order to write one.
> 
> Well, yes, you'll have to learn a couple of things :).
>
> > STL is all about algorithms and allowing the client to write
> > custom algorithms is what I really enjoy about its design.
> 
> That's very much what MPL is about as well.
> 
> > 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.
> 
> There will be a "guide to writing MPL algorithms"! Also, I believe that a
> couple of sections in the MPL paper (for example, "2.3.4 iter_fold as the
> main iteration algorithm") already cover a little bit of the topic.

Great! I'm looking forward to this. Yes, there was indeed some information
relevant to writing algorithms, however, they seem to be scattered all
over the place. MPL is a great piece of engineering. My *only* point is
that I wish for a 1) "guide to writing MPL algorithms" and 2) separating the
core stuff that powers MPL algorithms *clearly*; so we can do this:

        STLish      Haskellish     Loki ?
        algorithms  algorithms
            \           |          /
             \          |         /
              \         |        /
               \        |       /
                \       |      /
                    MPL core

Many thanks
--Joel