Re: [boost] Preprocessor: documentation comment

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-06-16 14:58:25

> > Many of the recent changes cause compilation slowdown, because the new
> > macros are not yet optimized, but this should change in the future.
>
> I'm looking forward to that; unfortunately my programs already compile too
> slowly.

Hopefully, EDG/Comeau C++ will take a look at their preprocessor after they
finish up the export implementation.  Right now, I'm doing custom build steps so
that I'm not preprocessing with Comeau C++ (I use cl directly).  That requires
going some length to hide the hokey preprocessor implementation of VC++, but
when something takes less than a second on VC++ and takes 10 minutes on Comeau
C++, the extra build step is worth it.

> <diatribe>
> When we write these sophisticated metaprogramming libraries to make
> programming easier in a given domain, we want to be able to give these
> things to inexperienced users and handle all the nasty stuff
> behind-the-scenes. Even if we go to great lengths to give users reasonable
> error messages, if it takes them a long time to find out what's wrong with
> their code, it impairs the usability of even the best libraries.
> </diatribe>

I definitely agree.  However, there are some inherent limitations of the
preprocessor and specific preprocessors in general.  The only way to avoid that
is pass around an 'error-state' argument to everything in order to isolate and
resolve the problem.  Of course, that would require a massive redesign of the
entire library, and it would also degrade performance of the library.  For
instance, if each argument to each macro was 'checked' for validity.  This is
partly why I'm in favor of simple constructs that are predefined by the library.
It puts the burden of testing them on the developer of the library (who should
know what he is doing).

> > Preprocessor metaprogramming is very much like programming in a strict,
> > purely functional programming language. This will be even more true once
> the
> > new techniques will be fully incorporated and the user doesn't have to
> pay
> > so much attention to preprocessor limitations.
>
> That'll be nice. However, I firmly believe that even tools modeling a
> solid, reasonably well-known formalism like functional programming are
> still tools. Usability is important, and part of that is being able to
> approach the tool before you're fully comfortable with the formalism.

And also before you are fully comfortable with the tool.  The preprocessor
library, as is, doesn't provide some of the 'high-level' functionality that it
should.  This functionality could be considered by the library to be just
pre-made uses of the library.  It doesn't take adding much to the library as the
number of things that I'm talking about are small, direct support primitives for
C++ constructs.

> > The preprocessor library should not degenerate into a collection of
> special
> > case macros for special cases encountered by C++ programmers.
>
> I think part of the reason that keeps getting suggested is that people want
> a way to do an end-run around the learning curve. If you want to prevent
> the wrong constructs from getting library-ized, you need to make sure it's
> sufficiently easy for someone who "just wants to get a job done" to build
> them by hand.

I don't think it's just an attempt to bypass the learning curve.  It is that the
learning curve is to steep.  It is possible to categorize *levels* of use of the
library where certain constructs take less knowledge and understanding of the
library than others.  For instance,

level 1:
    simple arithmetic and logical operations:  ADD, SUB, etc.
    concatenation, stringizing
    -the kinds of pre-defined primitives that I'm talking about
    tuples, arrays
level 2:
    complex depth-relative arithmetic and logical operations:  ADD_D, SUB_D,
etc.
    (basically everything that ends with _D)
    cons-style lists
    list manipulation
    tuple/array manipulation
    use of looping and repeating constructs
level 3:
    everything that is only a partial solution to a general problem
    and requires putting different things together to get a result
    i.e. TUPLE_EAT, DELAY'ing types of macros, etc.

The problem here is that there are not enough items in the first 'beginner'
level.  It is big jump from level 1 to level 2 because level 2 requires that you
have a basic understanding of how level 1 constructs are *implemented*.  Because
the preprocessor is the way it is, there is nothing you can really do about that
except to provide level 1 support for 'casual' use.

> > Instead the
> > preprocessor library should make it significantly easier to build
> > application specific macros for the special cases needed by the
> application
> > developers.
>
> Bingo! Most of the work that's currently needed to achieve that is in the
> documentation, not the code.

True.  Both the documentation and the library itself need to work together to
flatten out the learning curve.  The documentation would help significantly.

> > Of course, the library should and does offer some support for
> > C++ language constructs.
>
> Yep. And the most commonly needed special case constructs shouldn't have to
> be re-invented by each user of the library.
>
> -Dave

I agree.  I know that there are some primitives already, such as ENUM_PARAMS.  I
just think we need a few more.

Paul Mensonides