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

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

----- Original Message ----- 
From: "David Abrahams" :

> > map, filter, concat, length, foldl, foldl1, scanl, scanl1, foldr,
> foldr1,
> > scanr, scanr1, iterate, repeat, replicate, cycle, take, drop, splitAt,
> > takeWhile, dropWhile, etc.
> >
> > Now if MPL's "conceptual" and "real" core can be delineated for
> > reuse in other contexts, I can write a subset of Haskell's prelude
> > using MPL's underlying infrastructure. I can do this while maintaining
> > conformance with MPL's conceptual framework, thus, maintaining
> > compatibility.
> 
> Hmm, sounds like you want a "guide to the implementation". I think the
> user guide is enough of a struggle that your request will have to wait a
> while.

Two points:

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.

2) If such a "conceptual" core is exposed and is fully understood, 
I could imagine that a MPL version of Loki can be built with ease
(relatively, than writing one from scratch). Thus, we complete the 
full circle and we have a solution to this A vs. B dilemma where 
we are in right now.

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