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

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2003-04-13 20:32:23

Joel de Guzman wrote:
> I'm sure I'll have more comments, but, small comments for now:
>
> 1) Which "forum that is quite biased against the preprocessor" do
> you mean? AFAICT,  template metaprogramming has stressed the
> resurgent need for the preprocessor. CPP use (or abuse :-) is no
> longer "heretic" these days :)... I used to be a CPP "hater", but ....

The scoping mechanism that is currently being looked at, from my point of view
and others, is purposely designed to inhibit use of the preprocessor--not help
it in any way.  It is a one-way facility.  It helps only the writers of code
where external macros might interfere; it doesn't help code where macros might
need to be defined.  Also I have been told by Daveed that the general
inclination is to *not* encourage use of the preprocessor in any way in the core
working group.

> 2) region is not intuitive, I'm gravitating towards "module", along
> with its friends "import" and "export".

I'll change it.  Either one suits me fine.

> 3) "The second major problem is the use of #< and #> as
> scoping directives.  These directives are difficult to see in code
> that contains many other directives, and this lack of visibility
> would visibly complicate code."
>
> --> Really? This is rather subjective, don't you think? While
> I prefer the explicit #module module_name, I think you should
> provide a convincing argument to substantiate your claim.

No, it isn't subjective.  Take a look at any Win32 header for example.  They are
so filled with directives and conditional compilation that #< and #> would be
even more difficult to match up.  I'm not saying, of course, that those headers
are the pinnacle of header design, but nevertheless, they are examples of real
code.  They also don't match the precedent set by every other directive.  It is
currently undefined to put anything after a null directive (#) except a comma,
so new "directive keywords" won't break any currently well-defined code.

> 4) I tend to think that nested #modules are not necessary and
> seems like an overkill. I wouldn't mind a flat, and simple #module
> layout.

Really?  What about all the prefixes that we now have in Boost?  BOOST_PP_ is
the simplest library-specific one there is.  We also have BOOST_PYTHON_, etc..
This would be better. IMHO:

# module BOOST
#    module PYTHON
#        define MAX_ARITY 15
#    endmodule
# endmodule

In regards to the pp-lib itself, I have many interface macros and many detail
macros.  Nested modules would allow me the type of name encapsulation that the
rest of the language takes for granted (and don't forget the fact that all-caps
names would no longer be necessary).

// library
# module boost
#  module pp
#    define enum_params(count, param) // ...
#  endmodule
# endmodule

// user code...
#module
#import boost::pp

template<repeat(5, class T)> class some_class { };

#endmodule

> 5) I wish to see how the proposal will have an impact with future
> C++ features. OTOH, there's talk about abolishing the CPP and
> replacing it with language mechanisms, continuing the inline
> and const that replaced macros from old C.

What things are you referring to here?  Some type of scoping mechanism is
already being looked at, but it is inferior.  The other features, variadic
macros and placemarkers, are from C.  Do you think that we should maintain
compatibility in this regard?  Token-pasting is an insignificant change that
simply cleans things up.

Regarding "abolishing the preprocessor", do you really think that this could
ever happen?

> For instance, the
> template book talks about variable template parameters. This
> feature will lessen the need for the CPP. In an ideal world, I
> would definitely want to program not in two languages,
> just one: C++.

This will never happen.  We will *always* need some type of tool to manipulate
source code as text--whether the tool is external to the language or not.
Integration into the core language is just another way of saying that we need to
continually add new major features to the language in order to keep up with the
people that are constantly pushing the boundaries.

> However, I also tend to think that C++ is
> already very heavy (and brittle?) that it would take a lot more
> effort to extend it to support features which are possibly in the
> domain of CPP.

This would definitely be the case for many things that I can think of, IMHO.
Some things, you are absolutely right.  Variadic templates would be very nice,
but a core language mechanism to generate permuted overloads?  Yeah, right!

Here's my basic point-of-view, Joel.  I know that, at this point, if I asked for
way too much, I won't get anything.  These things are relatively small.
Variadics and placemarkers from C99, token-pasting because it is a general
nuisance and minor, and a scoping mechanism because a) they are already
considering one, and b) it is insufficient.

Ideally, the preprocessor could be expanded to be a true, full-fledged,
macro/token processor--which it currently isn't, but we have to take small steps
to get there.

Paul Mensonides