Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: ANSI C preprocessor
Message-ID: <5524@brl-smoke.ARPA>
Date: Fri, 16-Jan-87 19:42:00 EST
Article-I.D.: brl-smok.5524
Posted: Fri Jan 16 19:42:00 1987
Date-Received: Mon, 19-Jan-87 23:43:21 EST
References: <4430@watmath.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Distribution: comp
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 38

In article <4430@watmath.UUCP> rbutterworth@watmath.UUCP (Ray Butterworth) writes:
>> From: gwyn@brl-smoke.ARPA (Doug Gwyn )
>> Subject: Re: RMS comments to X3J11 (LONG)
>> >2. A preprocessor directive that allows defining a macro so
>> >that each time it is called it appends some text to the definition
>> >of another macro.
>> I thought this could be done with the defined facilities.
>Which defined facilities are those?  They aren't available in the
>cpp here.  How does one write an ANSI macro X(a,b,C) that appends
>"a" to macro A and "b" to macro "B and "a b" to macro C?

Well, it isn't possible according to the rules to change the formal
definition (replacement list) of a macro as a side-effect of macro
expansion, for the following reasons:
	(1) non-benign redefinition is prohibited;
	(2) #undef doesn't help because macro expansion doesn't
		trigger additional preprocessor control actions.
There are fairly good reasons for insisting on these constraints.

What I had had in mind was an equivalent solution (done as more
than one preprocessor control action) such as:
	#define	TMP	NAME
	#undef	NAME
	#define	NAME	TMP ## new_stuff
	#undef	TMP
but I should hasten to point out that this idea was a mistaken
notion on my part, because replacement is done when a macro is
invoked, and only the latest definitions would still be "known"
at that time.  I apologize if I misled anyone.

I suppose the important point is that C preprocessing is NOT a
general-purpose macro facility such as M4.  To be one, it would
need to support recursion during macro replacement, either an
"eval" or a "quote" operator, non-benign redefinition, and other
things that never were considered to be permissible for C
preprocessing a la K&R.  Perhaps a future language ought to
consider mandating a general macro facility; I agree that it
would be useful to have one.