From: utzoo!decvax!cca!Michael.Young@Cmu-10a@sri-unix Newsgroups: net.unix-wizards Title: Re: C extensions Article-I.D.: sri-unix.3958 Posted: Fri Oct 22 03:20:42 1982 Received: Sat Oct 23 01:03:23 1982 From: Michael Wayne Young Date: 19 October 1982 1409-EDT (Tuesday) How about this one: a 'constant' type class. [Is this what you meant by 'classc'? If not, what did you mean?] I also would like to see some true incorporation of the proprocessor into the language -- who uses one without the other? [I guess some people use m4 to preprocess their source, but then this doesn't prevent cpp from being used too.] If we could get the preprocessor merged with the compiler, I'd like to be able to build "packages" (to borrow an abused Ada term) consisting of external and/or macro definitions. Instead of using "include" files which just contain information that gets built into symbol tables (in cpp or ccom/c0,c1), we could have the compiler SAVE these things, and include the compiled tables instead. This would cut down on a lot of "include" file scanning, and shouldn't be too tough to do; however, it does mean a different compiler organization. Another interesting question I have is: why can't union types be initialized That is, as long as your initializers make the choice of the unioned types unambiguous, what's the harm I recognize that it's not a really good programming practice, but being able to initialize unions does make them more useful, and I've seen lots of code that just chose to use (very non-portable) alternatives to unions for similar reasons. And then how about a language-defined variable-length argument list construct. I'm not sure how I'd like to see this done, but have several interesting thoughts on the matter. This unfortunately requires that the implementation of routine-call code be restricted a little bit, but most implementations of C use the PDP-11/Vax style of parameter-passing already, and that's what we want to see. Along the lines of in-block variable declarations, I'd be interested in seeing a "retire variable;" or "register variable" statement set that could suggest to the compiler that a variable can be thrown away at this point (lexically, in the source), or that at this point, it'd be wise to make the variable given a register variable. Again, this is a hack, but it's nice to be able to have a whole bunch of register-class variables (with differing names, for clarity of code) but not have them all active at once. [Perhaps a backup in 'automatic' space would be appropriate.] Also, much of this facility can already be provided by a "smart" compiler that chooses its use of registers carefully, but often the programmer knows better what his register-class variables ought to be. About string operations: I in fact would suggest NOT adding them to the language for the same reason that I don't want to see multi-precision arithmetic added... packages of subroutines are good for such things. If you really insist, what I'd suggest is to add a construct for binding operation symbols to routines, somewhat like the Ada overloading technique. Compilers shouldn't have the added responsibility for supporting structured, or complex, types -- for one thing, they fix the implementation, and for another, I would rather have my compiler not have to worry about it. In the last year or so, I've often thought of neat things that could be added to the language, but I've restrained saying anything about them, for the primary reason that C is a very clean-looking, simple, and yet portable, language. [One reason I don't suggest very large changes is that lots of sites still run V6 and V7 Unix, and the V6 compilers, as we all know, are very archaic, but much of the currently-deveoped C code still compiles there. We don't want to pull a change (like from 4.1 ==> 4.2 BSD) that loses half of our audience.] Michael