Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!henry From: henry@utzoo.UUCP (Henry Spencer) Newsgroups: net.lang.c Subject: Re: ANSI C and the C Pre-Processor Message-ID: <4403@utzoo.UUCP> Date: Tue, 2-Oct-84 12:32:48 EDT Article-I.D.: utzoo.4403 Posted: Tue Oct 2 12:32:48 1984 Date-Received: Tue, 2-Oct-84 12:32:48 EDT References: <1691@pegasus.UUCP>, <4335@utzoo.UUCP>, <4082@tekecs.UUCP>, <459@mulga.OZ> Organization: U of Toronto Zoology Lines: 55 > .................... K&R was never clear on this point - its > wording on this point (and others) was ambiguous. That is, > a perfectly viable interpretation, taken by Reiser, was that > strings in the token sequence could be scanned for parameters. Point taken, K&R was never entirely clear on this, but it *sounded* clear enough that a lot of people just assumed "no substitution inside strings". Including a lot of implementors. > The problem is that K&R is *not* a standard. If it was, we wouldn't > need X3J11... On the contrary, ask most C compiler implementors outside Bell and they will tell you that K&R is the standard they worked from. It is true that K&R is not precise enough or complete enough to be an ANSI-quality standard, but anyone who denies that K&R has been a *de facto* standard for quite some time is kidding himself. A poor one, yes, but a standard. > No-one is asking for a full blown macro processor, just that subset > that is really useful for C programs... The trouble is that "really useful" is a subjective judgement. My personal view is that both token concatenation and in-string substitution are useless junk. I am quite aware that other people feel otherwise. Anyone who has looked at the implementation of the S statistics language has some idea of just how far "really useful" can be pushed. (Much of the S stuff needs *several passes* through m4 before compilation!) In practice, one has to draw the line somewhere. The question is not "is this feature useful?" but "is this feature useful *enough* to force *everyone* to implement it?". Saying "if you want fancy stuff, use m4" is not a cop-out, it is a statement that the committee is not going to solve all the world's problems. > Seems to me that in this case, adopting the Reiser interpretation > is the better thing to do. Document it clearly, so people aren't > trapped, and that should end the problems. My impression is that the committee's biggest problem with this is that retrofitting the Reiser interpretation into existing compilers is not necessarily easy. A good many compilers do *not* do the preprocessing as a separate text-manipulation step first; their "preprocessors" are integrated into the scanner, or following it. Pulling tokens apart again into text, and then reassembling them, isn't trivial. The current committee notion (substitution only on whole strings) avoids much of the complexity of this. One can argue that issues of current implementation are not significant, that the future users should be the primary consideration. This ignores a nasty pragmatic consideration: if the standard is going to fly, standard-conforming implementations are going to have to be common. It would really be nice if existing compilers didn't have to be rewritten from scratch. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry