Re: [boost] Submission: typelist

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-12-12 15:18:56

From: "Mark Rodgers" <mark.rodgers_at_[hidden]>
> From: "Peter Dimov" <pdimov_at_[hidden]>
> > Because it's not a push_back.
> >
> > push_back(c, v) is a mutating operation on c. After it c has one
> > additional element pushed to its back, v.
> >
> > append(a, b) is a pure function that returns the concatenation of a and
b.
>
> I see your point but I think "harmful" is perhaps a little strong.  I will
> concede though that the advantage of reusing "push_back" is more open to
> debate than some of the other examples.
>
> Personally, I still favour push_back.

I can live with a "functional" push_back, but it's not the same as (or more
basic than) append.

One problem with the "functional" push_back is that programmers will be
mislead by the analogy with the STL, where push_back is more frequently
supported than push_front. In our case push_front is a primitive:

(let's assume that the pair data structure A.B is called pair<A, B>)

template<class List, class Value> struct push_front
{
    typedef pair<Value, List> type;
};

while push_back is (much) more taxing (since it's effectively a form of
append):

template<class List, class Value> struct push_back;

template<class F, class R, class V> struct push_back<pair<F, R>, V>
{
    typedef pair<F, typename push_back<R, V>::type> type;
};

template<class V> struct push_back<nil, V>
{
    typedef pair<V, nil> type; // append would have had typedef V type;
};

It's true that programmers would rarely need to write this kind of code
(especially if they have MPL at their disposal) but they would still need to
be able to understand what happens under the hood, and the false STL/meta
analogy isn't going to help them. push_back(L, V) is usually O(1) in STL,
but O(|L|) in "meta."

--
Peter Dimov
Multi Media Ltd.