Re: Boost Workshop at OOPSLA 2004

From: galathaea (galathaea_at_excite.com)
Date: 08/15/04 

Date: 15 Aug 2004 07:02:50 -0400

"Andrei Alexandrescu \(See Website for Email\)" <SeeWebsiteForEmail@moderncppdesign.com> wrote in message news:<2nqfupF3fjgkU1@uni-berlin.de>...
> "Jeremy Siek" <jeremy.siek@gmail.com> wrote in message
> news:21925601.0408090845.4a6d6a7c@posting.google.com...
> > CALL FOR PAPERS/PARTICIPATION
> >
> > C++, Boost, and the Future of C++ Libraries
> > Workshop at OOPSLA
> > October 24-28, 2004
> > Vancouver, British Columbia, Canada
> > http://tinyurl.com/4n5pf
> [snip]
>
> I wonder if the submitters follow this post's trail or I should email
> them... anyway, here goes.
>
> I am not sure if I'll ever get around to writing it, so I said I'd post the
> idea here, maybe someone will pursue it. In short, I think a proposal for a
> replacement of C++'s preprocessor would be, I think, welcome.
>

There is only one replacement for the c++ preprocessor which I would
consider truly up to c++'s potential as a competitive language into
the near future: metacode. Full metacode capabilities, not just a
minor update to template capabilities.

By this I mean the capability to walk the parse tree at compile time
and perform transformations in a meta-type safe manner (analagous to
full second-order lambda capability such as System F). Vandevoorde's
metacode seems a good step in this direction, but I really think that
such a proposal must be as complete as possible (and not a library
proposal but a full language extension).

Consider some of the things I've seen talked about recently on the
newsgroups. Injecting a function call after all constructors have
executed is certainly one of those things the language should allow,
but currently we must work 'around' the language by forcing the use of
factories in such cases or leaving the two-stage use to clients (never
a good idea). In terms of functional relationships, though (even in
the presence of exceptions), such a task is a simple injection in
terms of functional orderings of the ctors and we are currently made
to fight with the language definitions enforced by the compiler.

Or consider the place where I currently use the Boost preprocessing
library the most: serialisation of classes. If we were allowed to
walk the member list for a class, walk its inheritance graph, and
stringise the class names (or produce better unique identifiers),
serialisation would be a cakewalk. Unfortunately, it is made much
more difficult and requires a more difficult object definition model
if any of the tasks of serialisation are to be automated by a library.

And of course there is all that control over the exception path
process, pattern generation, and general aspect functionsl
relationship injection that programmers have been crying about for
years.

> Today Boost uses a "preprocessor library", which in turn (please correct me
> if my understanding is wrong) relies on a program to generate some many big
> macros up to a fixed "maximum" to overcome preprocessor's incapability to
> deal with variable number of arguments.

Others have pointed out that this is much more a nonconformance issue
than it is an inherent preprocessor limitation, but I'd like to stress
that a fully recursive code generation system in c++ would not present
such problems.

> Also, please correct me if I'm wrong (because I haven't really looked deep
> into it), but my understanding is that people around Boost see the PP
> library as a necessary but unpleasantly-smelling beast that makes things
> around it smelly as well. [Reminds me of the Romanian story: there was a guy
> called Pepelea (pronounced Peh-Peh-leah) who was poor but had inherited a
> beautiful house. A rich man wanted to buy it, and Pepelea sold it on one
> condition: that Pepelea owns a nail in the living room's wall, in which he
> can hang whatever he wanted. Now when the rich man was having guests and
> whatnot, Pepelea would drop by and embarraisingly hang a dirty old coat. Of
> course in the end the rich man got so exasperated that he gave Pepelea the
> house back for free. Ever since that story, "Pepelea's nail" is referred to
> as something like... like what the preprocessor is to the C++ language.]

You are certainly a storyteller, but I'd give the c++ preprocessor
more credit. It has been the only method to acheive certain
limitations (shortfalls in complete second-order lambda
expressiveness) when needed by the coder. Indeed, if you take one of
the coders duties as minimising the updates needed by future feature
revisions of other coders, the preprocessor has always had its place
secure from typed language features. Again, serialisation has been my
major use, but other reasons for, for instance, type to string
conversion include interception of API's through lookup in the
import/export lists of the modules. A full metacode capability would
make that obsolete (walking the symbol table should be as easy as
walking the parse tree itself).

> That would be reason one to create a new C++ preprocessor. (And when I say
> "new," that's not like in "yet another standard C++ preprocessor". I have
> been happy to see my suggestion on the Boost mailing list followed in that
> the WAVE preprocessor was built using Boost's own parser generator library,
> Spirit.) What I am talking now is "a backwards-INcompatible C++ preprocessor
> aimed at displacing the existing preprocessor forever and replacing it with
> a better one".

Certainly full metacoding capabilities would make this obsolete...

> If backed by the large Boost community, the new preprocessor could easily
> gain popularity and be used in new projects instead of the old one. To avoid
> inheriting past's mistakes, the new preprocessor doesn't need to be
> syntax-compatible in any way with the old preprocessor, but only
> functionally compatible, in that it can do all that can be done with the
> existing preprocessor, only that it has new means to do things safer and
> better.
>
> I think that would be great. Because it we all stop coding for a second and
> think of it, what's the ugliest scar on C++'s face - what is Pepelea's nail?
> Maybe "export" which is so broken and so useless and so abusive that its
> implementers have developed Stockholm syndrome during the long years that
> took them to implement it? Maybe namespaces that are so badly designed,
> you'd think they are inherited from C? I'd say they are good contenders
> against each other, but none of them holds a candle to the preprocessor.

If we extend the idea of metacode to all of the translation process,
in other words if the programmer were to have control points inserted
into all parts of the code generation process, then export would never
have been a problem to begin with. Unfortunately, the c++
standardisation community feels that processes like linking are
sacrilege and not to be touched by regulation. If a full parse tree
walk were to include the ability to load other translation units and
manipulate their trees, then we wouldn't find export a 'scar' or in
any way difficile.

You know, if the c++ committee had the cojones to make standardisation
over the full translation process, we might even see dynamic linking a
possibility for the next language revision.

> So, a proposal for a new preprocessor would be great. Here's a short wish
> list:
>
> * Does what the existing one does (although some of those coding patterns
> will be unrecommended);
>
> * Supports one-time file inclusion and multiple file inclusion, without the
> need for guards (yes, there are subtle issues related to that... let's at
> least handle a well-defined subset of the cases);
>
> * Allows defining "hygienic" macros - macros that expand to the same text
> independent on the context in which they are expanded;
>
> * Allows defining scoped macros - macros visible only within the current
> scope;
>
> * Has recursion and possibly iteration;
>
> * Has a simple, clear expansion model (negative examples abound - NOT like
> m4, NOT like tex... :o))
>
> * Supports variable number of arguments. I won't venture into thinking of
> more cool support a la scheme or dylan ofr Java Extender macros.

I'm not a big fan of textual macros when typed completion gives the
same computational capability. I really think that metacoding,
architecture generation, and all of those great things we come to look
for in AOP and generative intentional programming is what the c++
standards commitee should focus on. With that type of capability, a
"pre"-processor is superfluous.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

galathaea: prankster, fablist, magician, liar

      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]

Relevant Pages

  • Re: Cpp Considered Harmful
    ... > One is to present the 'raw' interface of the template to the user. ... easier than they can parse the underlying language itself. ... resulting from the preprocessor, it merely has to preprocess it. ... > Using JBuilder, and the Java counterpart, I can fly through XML ...
    (comp.lang.cpp)
  • Re: Cpp Considered Harmful
    ... ordering, template declaration instantiation, etc.. ... I think you have a serious misunderstanding of the preprocessor. ... Parsing Java is quite a bit simpler than parsing C++. ... >> source code much easier than they can parse the underlying language ...
    (comp.lang.cpp)
  • Re: Cpp Considered Harmful
    ... That is why assertions are preproccessed away in production code. ... What I've seen done with Java IDEs has shown me that they can ... In C++, because of the preprocessor, you cannot really be sure that what ... that you apparently want to enforce coding policy by language design. ...
    (comp.lang.cpp)
  • Re: Software Development: maintenance vs. hardcore coding
    ... Support should be part of the language. ... Since very few people really build Java projects in the realy world by ... that would be no different from the C preprocessor, ...
    (comp.lang.java.programmer)
  • Re: INCLUDE functionality
    ... multiple programs, but which are not suited to be coded as external ... routines. ... preprocessor to expand the code and then run it. ...
    (comp.lang.rexx)