The D Programming Language

[Chris Torek]

In article <2718 at mmintl.UUCP> franka at 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 <stmts> while (<exp>) next <stmts> do <stmts> end;".
>The "while" and "do ... while" I would generalize to "loop <stmts> while
>(<exp>) <stmts> 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
<strings.h> (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 at mimsy.umd.edu		Path: not easily reachable