Re: [boost] Preprocessor: documentation comment

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-06-16 13:04:11

----- Original Message -----
From: "Vesa Karvonen" <vesa_karvonen_at_[hidden]>

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

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

> >The problem here is not showing how something *can be* used, it is
showing
> >what
> >types of things it *can be used for* in the scope of a larger system.
> >Building
> >blocks are pretty useless without a larger understanding of how to put
them
> >together to make something useful. In its own way, preprocessor
> >meta-programming is almost an entirely separate language and programming
> >paradigm, and that is hard to pin down with documentation.
>
> 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.

> In my opinion, the preprocessor library should support preprocessor
> metaprogramming. This support should be in the form of generic,
higher-order
> macros that either:
> - enhance the preprocessing abilities of the preprocessor (e.g. CAT,
> STRINGIZE, REPEAT), or
> - enhance the computational abilities of the preprocessor (by making it
into
> a complete programming language).

All good.

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

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

> 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