Boost logo

Boost :

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

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

> What functionality would you like to see delineated in this separate
> unit?
> > I bet it can be reused to power
> > other metaprogramming libraries such as well.
> Like the STL, the MPL derives most of its power from the fact that it
> provides a conceptual framework. When you peel away all the layers, what
> you have (as with the STL) are some powerful concept definitions. In
> MPL, some of the concepts are:
> metafunction
> metafunction class
> iterator
> sequence

Yes, that's what I meant.

> Honestly, I can't see why anyone thinks there is something
> non-fundamental/alien-to-FP about algorithms like find_if et al. Every
> functional language I've ever seen has such a thing, or quickly grows
> it.

I have no problem with find_if. It is things like erase, erase_range,
remove, replace, replace_if that I find, ummm, awkward in a purely
functional world. Some STL algorithms imply a destructive update.
This is ok in the domain where it was designed for (imperative C++)
but breaks down somewhat in the pure (no side effects) template
metaprogramming domain.

I would very much rather opt for things like:

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. I see no reason in arguing which set of algorithms is
better. Both can coexist.


Boost list run by bdawes at, gregod at, cpdaniel at, john at