Re: patch to add #pushdef, #popdef to cccp,cpplib

[Chuck Blake <cblake at lcs dot mit dot edu>]

> Gerald has the "default" behavior down just right.  By default we do
> not want to add any more language extensions.

Sorry.  The web page seemed to suggest you were encouraging exploration
of new language features.

> I haven't read your stuff in any detail yet (egcs-1.1 has priority),
> but when I do read them they'll have to make a very compelling argument
> to include them.

Sigh.  The patch is just content.  It is not jam-packed with compelling
arguments to justify its existence.  Lexical (non-)isolation of macros has
been a total pain forever.  Namespace management is important enough to
have several independent ways to do it in the C++ base language.  There
is essentially no containment at all in the preprocessor.  This is one
of several high order bits that make it error prone to use.

> [...] And in the process of getting wider exposure, they have
> uncovered fundamental flaws in the design of the asm extensions.

To me this sounds like an argument *for* egcs trying out extensions, not
against.  The drawback is it is hard to change the syntax.  But without
the exposure, it might never get designed right in the first place.  The
problems seem to arise from a reluctance to remove broken extensions if
they seem bogus or need re-working.  But I think egcs should have that
luxury.  Perhaps as a practical matter it does not.

I'd be the first to admit that my #pushdef idea may not be the optimal
way out of the problem.  Perhaps pushdef should (syntactically) work
more like #popdef and less like #define.

Or, perhaps in #pushdef, unlike #define, recursion should be allowed to
expand the *prior* definition of itself in replacement text.  This would
be pretty convenient in a lot of cases.  This doesn't have a recursion
problem as long as the replacement text does not contain the macro.

Or maybe it could, and the expansion would chase down the stack, the
only requirement being that the bottom of the stack bound the recursion
by not recursing past that point.  If the bottom-of-stack macro contains
itself, the expansion just gets itself.  This might be most useful of
all.  But there may be undesirable syntactic interactions with the
semantics of function-like macro argument lists.  I haven't really
thought that through.

And so on, and so forth.  There are lots of different things that could
be tried that would be a bit more work to implement than what I did.
I wanted to just put something out there to feel people out for this
style of extension.  It was not a "blindly add me to egcs" patch.
Before I would suggest it even go in for real I would want to add
documentation, configure options to turn it off, maybe hook into -ansi
to warn/disable, etc, etc, etc.

Chuck