Re: Understanding MPL

From: David Abrahams (dave_at_[hidden])
Date: 2003-04-17 19:01:56

"Paul Mensonides" <yg-boost-users_at_[hidden]> writes:

> Edward Diener wrote:
>
>> The general user does know how to use preprocessing macros and does
>> understand how the macros may get expanded to code which can be used
>> to accomplish tasks.
>
> This is flat out not true.  The general user understands that macros are
> relatively simple textual expansions.  The general user does not understand the
> details of macro expansion, and these details are extremely important for any
> effective use of the preprocessor metaprogramming.  

That is flat out not true.  I have made some effective use of PP
metaprogramming without understanding the details of macro expansion.

> Preprocessor metaprogramming and, to a large extent, template
> metaprogramming is all about manipulating/exploiting the "details"
> of their respective parts of the language.  I absolutely guarantee
> that this level of understanding does not generally exist--for
> template metaprogramming and especially for preprocessor
> metaprogramming.

In general libraries like MPL/Type Traits and Boost PP allow users to
ignore (or actually be ignorant of) many of those "details" and
concentrate on the task at hand.  That's in part what makes them so
powerful.

>> The general user does not understand the areas of functionality in
>> the Boost pp-lib, what they are and how they may be used, because
>> there is no good organizational explanation about the various areas
>> in which the Boost pp-lib can be effectively used to accomplish
>> either template programming goals or just useful code generation
>> goals.
>
> Both and more.  As I said in the post I just sent a few minutes ago, I will
> address this this weekend.  I'll try to write up a decent overview of the
> functionality available and send it to you so you can tell me what
> you think.

Is it done yet?  Can I see?

> However, there is no getting around the complexity involved because
> Cpp works against encapsulation.

Do you mean for example the leaking of information like recursion
levels and different recursion mechanisms into the library interface?
If so, I think that stuff is graspable without having to understand
the reasons for it.  You can just give people rules to follow and be
done with it.

>> What is needed, even given the difficulty of trying
>> to understand how the macros actually work with various possibly
>> broken preprocessors, is an explanation of the pp-lib from a user's
>> point of view, ie. what is there and what can it accomplish in terms
>> of helping to simplify program code generation and/or use.
>
> What can be accomplished is an open-ended question.  I can only
> provide examples of a few things that can be accomplished--which
> both Vesa and I have already done.

What you haven't done is to write something like, "C and C++ code
(especially library code) often contains lots of boilerplate
repetition, leading to fragile systems that are tedious to write and
maintain.  The Boost PP lib provides a programmatic framework for code
generation which can be used to eliminate repeated boilerplate and
factor out common textual patterns in code."
...and take it from there.  

>> As an example, I understand that there is part of the Boost pp-lib
>> which deals with easing the specification of repetitive constructs.
>> That could be discussed, macros which solve repetitive generation
>> problems can be discussed and explained, and the general user will
>> now have an idea of what macros in the pp-lib help with repetitive
>> programming problems and how a given macro may be used in that way.
>
> As I've said before, this categorization is already there:
> docs/headers/repetition/* I agree that this organization is not
> explicit, but it is there for anybody who cares to look deeply at
> it.  

The problem is that a general sense of the library and its
capabilities should be possible without looking deeply.

>> You may be right that the general user must first attempt to master
>> the arcana of macro expansion and what does and does not work many
>> macros attempt to expand inner macros in different situations in
>> order to even use the pp-lib at all.
>
> This is definitely part of it, but it has more to do with the
> vertical dependencies associated with the implementation of each
> primitive in the library.  How primitive X is implemented is a
> direct concern to primitive Y.  Expansion order is a significant
> factor as well.  Encapsulation is a huge issue that causes use of
> the library to be closely tied to the implementation of the library.
> I have spent an excessive amount of time attempting to minimize
> these dependancies.

And you did a good job, which means that most users don't need to
worry about it.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com