Re: [boost] Re: ATTN: All Developers Interested in Boost.Preprocessor

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2003-04-14 13:45:09

Vesa Karvonen wrote:
> Paul Mensonides:
> [...]
>> I need input regarding the paper itself and anything that should be
>> added or subtracted from the paper.
> [...]
>
> It looks quite reasonable and very conservative to me.
>
> It is difficult to imagine a really good reason not to adopt the C99
> preprocessor extensions into C++.
>
> Well-defined token-pasting is also reasonable.
>
> The way I see it, the module system is the only real extension - and
> the
> most difficult to justify. The way I understand it, the module system
> doesn't make the macro system much safer for macro users. It probably
> makes macros safer for users of ordinary libraries (who don't want to
> care about the macros). (The C preprocessor is nowhere near as safe
> as the hygienic (and mostly hygienic) macros of Scheme, for instance.)

Yes it would, primarily because macros are not inherited automatically into
nested scopes.  Therefore, you can "undefine" an unknown quantity of macros,
with unknown names simply by doing this:

#scope

// source code

#endscope

> I think that it would not necessarily be wise to use lowercase names
> for macros even with the module system. The problem is that within a
> module, you could still get all sorts of nasty surprises if you
> forget that you have imported a particular macro (a few hundred lines
> above). (Contrast this with Scheme hygienic macros, where ordinary
> bindings can shadow syntactic
> bindings and vice versa. In addition, hygienic macros in Scheme are
> also referentially transparent - not unlike templates in C++.)

You may be right about this, but it also depends on context.  That sort of
separation of context is actually _possible_ given a named scoping mechanism.

> Also, the syntax for referring to macros, e.g.
>
>   BOOST::QUALIFIED
>
> seems quite ambiquous to me. It looks like three separate tokens. Has
> someone implemented a module system that uses this syntax?

It is three separate tokens, subject to macro expansion and rescanning, etc..
When I was originally thinking about this idea, I thought that use of :: would
be bad as well.  However, there are just to many annoying problems that could be
solved by using :: for macro scope resolution as well as namespace/class
resolution in the core language.  A couple immediate examples of this:

std::assert?

I'm sick of thinking up different names for "assert" because it is a macro.
Even the vaargs facility of the core language, e.g. void f(int ...), is another
example.  I can never remember which parts are macros and which are not, and
therefore which ones are subject to qualification with std::.  Further, I can
never remember which ones are *guaranteed* to be or not be macros.  This is
partially because I seldom use the mechanism, but it causes me to do things like
this:

void f(int ...) {
    using namespace std; // !
    // use va_list, va_start, va_arg, and va_end
}

This is counter to the purpose of the namespace mechanism in the core language.
I'm dumping every symbol in the entire namespace into scope simply because
certain things may/or may not be macros.  Your right, of course, that facilities
such as these must be used with care.  However, that is the same with every
facility--particularly in C++.

Paul Mensonides