Re: [boost] Re: MPL containers and algorithms

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-08-11 16:36:02

> Are you saying that you think it would be better with only FP constructs in
> MPL? That would mean no iterators (I guess), and it might mean that you
> loose the familiarity from run-time programming. It would mean a large
> change, when going from one to the other. This is just what MPL tries to
> avoid, by instead presenting familiar constructs. This way, the transition
> may be smoother. This was also a point in the "Static Data Structures" paper
> that Doug mentioned.

My only real disagreement with the MPL is the abstraction caused by the
assumption of more than one sequence type being necessary.  As for the
functional environment, C++ template metaprogramming *is* a function
environment, therefore the most natural use of it is functional.  I don't have a
significant problem with the simulation of iterative constructs (i.e.
imperatives), but it is still simulation, and the primary use IMO should be
functional.  It is C++ programmers job to understand the environment in which
they work, not the other way around.

>> > to the use of multiple sequence types?  IMO, the correlation to the STL
>> breaks down at this point.
>>
>> Sequences is just one thing. Combination of metafunctions, lambda (not
found
>> it STL, but found in Boost.Lambda), etc. are also similar.

>The STL analogy applies specifically to sequences.

> Well, look deeper: "plus", "minus", "multiplies", "divides", function
> composition, etc. All parts of STL, as well. MPL resembles STL + BLL.

These things I am not disagreeing with.  Just the assumption that more than one
sequence type is necessary <period>.  The STL uses the above primary in the
service of sequence abstraction.  That is what I meant, but that is not what I'm
disagreeing with.  For example, with your compile-time exponentiation
metafunction, I think that having the arithmetic functions "evaluate" the
arguments themselves is a good idea, and I have no disagreement with its
design--other than it doesn't apply well to half compile-time arguments and half
runtime arguments. (see "Generative Programming" - Czarnecki & Eisenecker).

>I don't mean that the MPL
>has stuff that the STL doesn't or vice-versa.  I mean that the fundamental
>premise of the STL analogy is flawed with regard to sequences because the
actual
>reasons for that abstraction in the STL do not apply to template
>metaprogramming.  The only thing that you really get out of it is syntactic
>sugar and limited similarity to STL code--which is not nearly as strong of
an
>argument as you tend to make it (IMHO). :)

> This had nothing to do with sequences at all, and that was deliberate.
> Instead, it showed the power of abstraction in MPL, which lets you use the
> same algorithm for any type that satisfies the concepts. This is _precisely_
> the same way it is in STL.
>
> I suggest you look again.

How many times to I have to reiterate this?  I _do not disagree_ with many of
the abstractions in the MPL.  I disagree with the supposed need of multiple
sequence types.

> I haven't gone as strongly on the sequences-similarity to STL, but instead
> emphasisted the generic qualities. However, I find the iterator concept to
> be powerful in itself, in that it decouples sequences from algorithms.
> Regardless of efficiency issues, this is powerful in itself. It means that
> if you create a new sequence, you can use it with existing components.

Generality is only a quality if it is worthwhile--otherwise it is a waste of
time and actually _hurts_ performance (among other things).  I agree that
generality of functions like pow (or other arithmetic) benefit from abstraction,
but like you said, that has nothing to do with sequences.

> To take the last you say:

>The only thing that you really get out of it is syntactic
>sugar and limited similarity to STL code--which is not nearly as strong of
an
>argument as you tend to make it (IMHO). :)

> I understand you here talk about sequences, specifically, and not MPL in
> general. Where have I made this as such a big point, you say? I, and others,
> have said that the decoupling of sequences from algorithms may be useful in
> itself. In what way have I "tended to make this a strong argument"? I've
> said that measurements could give us more info about this. And that's
> something we have got now. I don't recognize my postings in what you say,
> here.

You have repeatedly said that similarity to runtime code was a great benefit.
Yes, many people have said the decoupling sequences and algorithms may be
useful, but *no one has proven it* or shown an such example.  Even your timing
examples only proved what I have already been saying.

Paul Mensonides