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