Re: Understanding MPL

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-04-03 18:09:21

Paul Mensonides wrote:
> David Abrahams wrote:
>> "Edward Diener" <eddielee_at_[hidden]> writes:
>>
>>>> What specifically would you have me do?  The pp-lib docs do not
>>>> attempt to explain the implementation of the pp-lib itself.
>>>
>>> I don't want an explanation of the inner workings of the pp-lib. I
>>> would like to see an explanation of the pp-lib which attempts to
>>> explain the functionality of it from the user's point of view.
>>> Something like a grouping of the macros in it from the point of view
>>> of general areas of functionality, with the specific macros grouped
>>> and explained within each area.
>
>> The preprocessor
>> library doesn't need to be that way.  Users don't need to understand
>> the ugly workarounds and nitty-gritty details of C++ preprocessor
>> implementations in order to use the library effectively.  I'm living
>> proof of that.  One might say that's the whole point of any
>> high-quality library.  An overview of the concepts and idioms users
>> need to understand in order to make use of the library itself would
>> be
>> a huge help.
>
> I directly recall, in a separate discussion between you and I, the
> words "idioms are what you need, my boy."  And this is precisely the
> problem.  The preprocessor lib is implemented in the language Cpp.
> This is a _different_ language than C and C++, despite the fact that
> it is part of C and C++.  When you write documentation for library X
> that is written in language Y, it is assumed that the user
> understands (more-or-less) the Y language--assuming no cross-language
> bindings.  With C and C++, you have 20+ years of literature on
> technique and idiom.  Template metaprogramming is relatively new, but
> it is _still_ implemented within the core language.  You _still_
> don't have to explain that 1 + 1 == 2 evaluates to true.  With
> preprocessor metaprogramming, there is no such backdrop.  The
> language is...different.  In some contexts, it is imperative, yet the
> language is definitely not imperative as a whole.  In others, it is
> functional, yet it is not entirely functional either.  Discussion of
> idiom and technique is closely tied to the language.  This, in and of
> itself, is a huge subject if taken on solely by the pp-lib docs.
> However, it gets even worse.  All but the most simplistic idioms and
> techniques will not work properly or not work consistently on most
> preprocessors.  Nearly all of the negative criticism the pp-lib docs
> get do not revolve around how to use the primitives provided.  It is
> about explaining pp-metaprogramming, which, in turn, is largely about
> the language defined by Cpp.  This is exactly why I say that you
> don't know what you're asking for.  A general overview of what the
> library can do is _not_ going to help in this regard, and a detailed
> explaination of how the preprocessor works and all the techniques and
> idioms that I know regarding pp-metaprogramming would require several
> hundred pages minimum.  Discussion of workarounds and hacks would
> make it even worse.  The fundamental problem, IMO, is not the pp-lib
> docs, it is that prospective users do not understand the Cpp
> language.

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. 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. 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.

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.

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. Or that likewise one must understand what can be done or
not done given broken preprocessors in various implementations to use the
pp-lib. I wouldn't say that is a failing of trying to use the pp-lib when
the complexity goes up to a high level, but I would say if that were really
the case, then the pp-lib has to attempt to create documentation which very
patiently and in a well-organized way attempts to explain the above issues
to the end-user. Creating examples of already complicated uses of pp-lib
macros, which the end-user can't possibly fathom yet, is not the way to
explain these issues.

It is possible that the Boost pp-lib is so intimately tied to template
metaprogramming ideas that it is not really for the normal end-user who is
just interested in knowing what it is all about and interested in seeing
whether or not its functionality can be applied to other tasks. I will
except this and, because I am not a template metaprogrammer in the Boost
sense although I am very interested in what can be done in this area, it is
simply not for me to understand or use. That's fine but I wonder if this is
really the case with the Boost pp-lib. Most other Boost implementations do
not require that sort of knowledge simply to be used by a C++ programming
end-user. I understand the MPL does and perhaps the Boost pp-lib does too.