Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mit-athena.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!bellcore!decvax!mit-athena!jc
From: jc@mit-athena.ARPA (John Chambers)
Newsgroups: net.lang.c
Subject: Macro Preprocessor Extensions
Message-ID: <49@mit-athena.ARPA>
Date: Fri, 25-Jan-85 09:10:10 EST
Article-I.D.: mit-athe.49
Posted: Fri Jan 25 09:10:10 1985
Date-Received: Mon, 28-Jan-85 06:34:59 EST
References: <249@talcott.UUCP>
Organization: MIT, Project Athena, Cambridge, Ma.
Lines: 22

> I would particularly hate to see "deep" macro functionality added,
> e.g., the ability to execute preprocessor directives inside expanded
> macros.
> 
> All who agree with me, show your support by NOT sending in your
> list of neat preprocessor extensions!

I'd second this, with the added comment:  Every Unix(tm) I've ever seen
had the m4(1) macro processor in its library.  Well, OK, maybe some don't,
but I betcha you could get a copy over the net if you wanted it.  It's a
much more powerful macro expander than C's feeble preprocessor.  I've used
it on a couple projects, and after you figure out how to quote things,
it's relatively easy to use.  It's real easy to tell make(1) how to run
things through m4.  Some versions of cc(1) even have an option to apply
m4 automatically.

How about if we restrict suggestions for new macro goodies to people who
have learned to use m4?  Then we could skip over the problems that have
already been solved, and maybe talk about the problems that are really
still with us (since m4 is itself not exactly perfect).

			John Chambers