Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!umd5!trantor.umd.edu!chris From: chris@trantor.umd.edu (Chris Torek) Newsgroups: comp.lang.c Subject: Re: The D Programming Language Message-ID: <2327@umd5.umd.edu> Date: 20 Feb 88 14:16:40 GMT References: <11702@brl-adm.ARPA> <243@eagle_snax.UUCP> <2245@geac.UUCP> <2718@mmintl.UUCP> Sender: ris@umd5.umd.edu Reply-To: chris@trantor.umd.edu (Chris Torek) Organization: University of Maryland, College Park Lines: 107 In article <2718@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >Any serious effort to design a successor to C (which does not attempt to be >upward compatible) should first consider what should be taken out and/or >done differently. Adding new things is secondary. Uh oh. A ray of sensibility on the net! :-) Oddly enough (or perhaps given the impending Standard, it is not so odd), I have been considering the same sort of thing myself. For those who want to wade through details (such as they are), they appear below. One of the nicest things about the C language is what it does NOT do. The language is small enough to learn and comprehend entirely in a short time; the list of language oddities is not empty, but is small (most of them appear below). >The first thing I would remove is the automatic conversion of arrays to >pointers. I am not sure I would make this `first', but I agree. In fact, this is a side effect of what I would do with aggregate types. >Second on the list is defaulting of variables. An undeclared variable >should be an error, not an int. (An undeclared variable *is* an error, unless you claim `register i' leaves `i' undeclared.) >Likewise for functions. agree; unsure about C++/ANSI syntax >Another thing that should go is the assumption that the unit of storage is >the byte. I thought about this; it gets sticky, and I am still unsure. C's structure bitfields are the wrong way to get at bits; in particular, it would be nice to have arrays of bits. But the basic unit of storage has a way of creeping into the rest of the language, no matter how hard one attempts to keep them apart. >I would also like to do away with having control statements control single >statements. For example, instead of writing "if (foo) {stmt1; stmt2;}" I >would write "if (foo) stmt1; stmt2; end;". Likewise, I would rewrite the >"for" statement as "for while () next do end;". >The "while" and "do ... while" I would generalize to "loop while >() end;". I disagree with the details, but will note that some human factors studies have shown (and I agree) that a paired `end' is better than a single `end', e.g., `if e stmts endif', `while e stmts endwhile'. On the other hand, other studies have shown that `noise words' inhibit understanding. I am undecided about this. >Another shortcoming to be fixed is the automatic fallthrough for select >statements. agree >To get even more radical -- with typedefs, enums, const declarations, and >(if we add them) inline functions, do we really need the pre-processor any >more? Probably. Inline functions should most certainly be added; they nearly obviate the need for macros. >I would omit the automatic insertion of a null byte at the end of character >constants. If you want nul terminated strings, write the nul. If you want >strings with counts, the language should not get in your way. A general aggregate constructor is necessary. A specific version of one that constructs null-terminated strings might be declared in (or its equivalent). I would like to be able to create C-style arrays (blocks of memory) as easily as `real arrays' (with dope vectors). If I could come up with some way of merging arrays and structures/unions into a single `aggregate' type.... >I think I would also drop the convention that 0 is a null pointer. Make >"null" a keyword, representing a null pointer of any type. This would, at one stroke, eliminate half the confusion that plagues comp.lang.c .... (about 1/3 :-) ) I think the following are important considerations: - the language should be made as small as possible, but no smaller. - we should assume that compilers for this language are going to do a great deal of optimisation; in particular, they will optimise across entire compilations, not just single files. - it should be relatively easy to translate `old C' to the new language. - it might also be a good idea to steal liberally from C++ (which of course steals liberally from SIMULA and others). Very few of my ideas along this line are firm. My biggest worry is that if the language is too small and malleable, it will suffer from the same problems as some of the old dynamically-extensible languages. One solution is to make the language small but the support `library' (including headers that define standard aggregates like C-style arrays and strings) a `part' of the language. -- In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163 (hiding out on trantor.umd.edu until mimsy is reassembled in its new home) Domain: chris@mimsy.umd.edu Path: not easily reachable