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: Fuel for your flames: Things I would like in CPP Message-ID: <4405@utzoo.UUCP> Date: Tue, 2-Oct-84 12:56:24 EDT Article-I.D.: utzoo.4405 Posted: Tue Oct 2 12:56:24 1984 Date-Received: Tue, 2-Oct-84 12:56:24 EDT References: <9225@watmath.UUCP> Organization: U of Toronto Zoology Lines: 27 These suggestions are interesting, but I suspect that the response to some of them should be "if the ANSI C committee tries to solve all the world's problems, the ETA of the standard is roughly 2357 AD". The realities of building standards dictate that one sometimes just has to say "there is no standard-conforming way to do X", because the list of possible Xs is nearly infinite. Deciding to build something with approximately the same power as the current C language may be a cowardly decision, but bravery is not necessarily a virtue in a standards effort. It is also worth noting that (please correct me if I'm wrong on this, Kevin) there is no operational experience with any of these things. Standard committees have to decide, quite early on, whether they are going to try and invent new solutions, or try to stick very closely to things that are well-understood and proven in action. The latter approach is generally safer, and seems to be the prevailing mood of the ANSI C folks. > And with a well-written CPP, none of these changes are terribly difficult > to implement. You're sure? Including the CPP's that are integrated into the scanners of compilers? I'm not saying you're wrong, just saying that this strikes me as a very bold statement indeed. There is more than one (good) way to implement a CPP, and some of them may not lend themselves to such changes. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry