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

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-11 07:20:47

----- Original Message -----
From: "joel de guzman" <djowel_at_[hidden]>

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

Yes, and it's a false implication.

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

Just think of it as a way to avoid learning new names if you're a C++
programmer. Instead of mutating the sequence, which is of course
impossible, the algorithms construct a new sequence and returns it, very
much like the ones you list below. Many of these algorithms are in fact
simple and elegant, and don't seem to be "fighting the language" at all.
I think it's just a matter of what you're familiar with.

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

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.

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

-Dave