Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site rlvd.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!mcvax!ukc!warwick!rlvd!caag From: caag@rlvd.UUCP (Crispin Goswell) Newsgroups: net.lang.c Subject: Re: "C" wish list. Message-ID: <895@rlvd.UUCP> Date: Fri, 25-Oct-85 09:35:33 EST Article-I.D.: rlvd.895 Posted: Fri Oct 25 09:35:33 1985 Date-Received: Tue, 29-Oct-85 00:46:10 EST References: <335@graffiti.UUCP> Reply-To: caag@rlvd.UUCP (Crispin Goswell) Organization: Rutherford Appleton Laboratory, Atlas Buildings, U.K. Lines: 90 Keywords: language design C C++ strong typing Xpath: warwick ubu In article <335@graffiti.UUCP> peter@graffiti.UUCP (Peter da Silva) writes: >what features would you add to 'C' if you were god or some other moral >equivalent of Dennis Ritchie? Are you listening, Dennis Ritchie? > >Here are some wishes that the recent discussions have woken in me: > > 1. Extend the syntax of bit-fields to ordinary numbers > 2. Allow auto aggregate initialisations > 3. Allow constant aggregates > 4. Allow true block structuring > 5. Add some real programmability to cpp. I'm one of those people who think that structs should be first class objects in C. Doing this properly could probably be done fairly easily. I don't think array aggregates could be added and remain in the spirit of the language, because of the intimate relationship between pointers and arrays. This would seem to require a non-linear address space. There is a language called C++ which is a (nearly) upward compatible superset of C, which provides some features that are on my wish list, but few of those you have mentioned. I don't have a reference to hand, but it is fairly well known. My wish list has things to remove from C, so I could not really call the result 'C', in any form. I largely agree with your list, though I'm not sure what 5. refers to. Generics? 1. I'm not a fan of cpp. I believe the features it provides should be part of the language proper. C++ provides constants, and inline functions, which should remove the need for macros. I like these, though the circumstances under which it is possible to use inline functions in C++ are unfortunate, since it is a direct result of the way separate compilation is usually achieved on UNIX. The latter leaves much to be desired. 2. I'm not in favour of #ifdef. I believe that machine specifics should be in separate files, and my programming methodology usually makes this easy to achieve. 3. Make static the default for global values, rather than extern (C++ does this). 4. Remove the default declaration of names to int. This is reminiscent of FORTRAN, and causes many problems. C++ doesn't do this, presumably because it breaks too many programs. There are many things that lint(1) checks which belong in the compiler. C++ does cross-'module' type checking better than C. The ANSI C standard adds checking of function arguments, I'm told. I haven't read it yet. 5. There are various parts of the syntax that I don't like: 1. = for assignment, bring back := 2. ;'s as statement terminators, I prefer the algol statement separator. 3. I don't like anonymous blocks. I like IF ... FI. I think Algol68 got this right. switch is not nice, but neither is Algol68's case. 6. Nameless functions would be useful. It is already possible to pass function pointers around (this business about taking the address of a function needs to be tidied up. Does anyone know what ANSI says about this?). It would be useful to make functions first class objects as well, so that one could have an aggregate of function bodies with no names. There are probably difficulties of scope with this, which may make it impractical for a language like C. 7. C needs modules: either the current method of treating a file as a module needs to be formalised, or some module structure should be added. I'm not sure what is the best answer to this one. 8. There has been much discussion recently about ints, shorts and the like. I hate to say this, but Ada seems to have the right sort of facility. Perhaps it could be simplified so that mortals can use it. Keeping the size of a number range in the abstract is probably good, and people who *know* they want a particular size for a particular dirty application can choose the range which will get them the size they want. There are separate issues regarding the use of shorts and ints: speed vs. space and fixed format data. Speed vs. space should probably be achieved with Compiler directives as it should not affect the semantics of a program. Fixed format data should probably be handled with user defined types created specially for the purpose. I hope it is clear to everyone reading, that I am not suggesting these changes be made to C. They would constitute a new language entirely, which is not sufficiently different to be worth designing at this stage. I am interested in comments however, since I may one day sit down and do this. I'm dissatisfied with C, but C++ doesn't fill some of the gaps I would like filled. Crispin Goswell.