Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-14 20:19:02


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

> I think that effort must concentrate more on:
>
> 1) using map and fold instead of iterators to implement algorithms.
> In most FP languages I know, these higher order functions are
> the most used all over the place.

The library uses whatever high-level techniques are appropriate. Why do
you care if it uses iterators (and BTW, iterators are sometimes
important; don't knock 'em).

> 2) the porting of fold and map (is there a map?) to less conformant
> compilers.

They already work on MSVC6. I don't think we're targeting anything
less-conformant.
(map is called transform, last I looked).

> Regards,
> --Joel
>
> 3) OK, just my personal wish: Use more FP sounding names. This is
> all about FP, no more, no less. Pattern matching, recursion,
> higher order functions, fold, map, curry, lambda, the list goes on...
> Clearly, the STL authors are knowledgable with FP. STL is a good
> start in introducing FP (stealthily) to the C++ programmer. It is
> my opinion that we should extend that further. Why do we seem to
> underestimate the C++ programmer. C++ programmers are the
> **BEST* in the world (Period :-).

Personally I've grown comfortable with STL names like for_each,
transform, and accumulate (and honestly, I still haven't got the meaning
of "currying" to stick in my brain). MPL capitalizes on this familiarity
the same way that C++ capitalizes on C (but with less baggage). Really,
this seems like a somewhat frivolous request. The library provides fold.
If it only provided transform I could write:

    template <class Sequence, class Function, class State>
    struct fold : mpl::transform<Sequence, Function, State> {};

Why the big deal about "FP-ish naming"?

-Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk