Re: Re: typelists: MPL tutorial + partial review

From: Dave Gomboc (dave_at_[hidden])
Date: 2001-12-12 15:17:49

>    From: "Peter Dimov" <pdimov_at_[hidden]>
> Subject: Re: Re: typelists: MPL tutorial + partial review
>
> But for_each is not map, AFAIK. for_each can change the sequence it's
> applied to. Functional languages don't. Even transform is not map.

I agree that for_each != map, but whenever I use for_each/transform I
use it like I would use map, which is why I make the association.
There's this disconnect where functional programming languages do not
permit binding a new value to a variable, but C++ does.

// standard ml

fun map' (f, nil) = nil
  | map' (f, h::t) = (f h) :: map' (f, t)

map' (fn x => x+1, [1,2,3,4])

( => [2,3,4,5] )

// pseudo-c++

int main(void) {
    std::vector<int> x = {1,2,3,4};  // remember, pseudo ;-)
    class f {
        int operator()(int a) { return a+1; };
    };
    transform(x.begin(), x.end(), x.begin(), f);
};

( x = {2,3,4,5} )

Sure, in C++ x is bound to a new value, while this doesn't happen in the
SML version, but the intent of the developer is the same.  If the C++
writer didn't want the optimisation of an in-place update, they'd have
used a different third argument to transform.  It's even possible that
under the hood, an SML compiler would do the in-place optimisation, if
it could deduce that x wasn't needed anywhere else and was therefore
garbage afterward.

I still think that for the purposes of naming, the name used with C++
metaprogramming should be the same as the name used with C++ non-meta
programming, when the intent is the same.  (And if the C++ term is
accumulate as opposed to for_each, so be it.)  But the cons operation
deserves to be called push_front in compile-time C++, even if run-time
C++'s push_front isn't exactly the same.

Dave