Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!brl-adm!umd5!ames!pasteur!ucbvax!hplabs!decwrl!labrea!glacier!jbn
From: jbn@glacier.STANFORD.EDU (John B. Nagle)
Newsgroups: comp.lang.c
Subject: Re: The D Programming Language
Message-ID: <17320@glacier.STANFORD.EDU>
Date: 20 Feb 88 19:33:19 GMT
References: <11702@brl-adm.ARPA> <243@eagle_snax.UUCP> <2245@geac.UUCP> <2718@mmintl.UUCP> <2327@umd5.umd.edu>
Reply-To: jbn@glacier.UUCP (John B. Nagle)
Organization: Stanford University
Lines: 35


     Let me suggest a few ground rules for designing a successor to C:

     1)  It need not be upward compatible with C, but automatic upward
	 translation should be possible.  At the very least, automatic
	 translation with reliable automatic flagging of nonportable
	 constructs should be possible.

     2)  Syntactic changes should be avoided unless a definite gain can
	 be shown.  "I like it better another way" is not sufficient.
	 Changes to syntax tend to arouse opposition all out of proportion
	 to their importance.  The major problems in language design are
	 not syntatic.

     3)  C started life as a weakly typed language, and has been modified
	 slowly into a strongly typed one.  This has resulted in some
	 strange semantics.  This needs to be dealt with.

     4)  The basic model of a static language close to the machine should
	 be retained.  Attempts to bolt on a very dynamic environment
	 with heavy underlying machinery, along the lines of LISP or
	 Smalltalk, should be resisted.  

     5)  The semantics of types is probably the most important issue
	 to be addressed.

     6)  The semantics of finite-precision integer arithmetic need to
	 very well thought out.  The semantics of arithmetic should
	 be independent of the underlying hardware, so that the same
	 answer is obtained on all machines for all valid operations.
         (This is possible, and can be done efficiently, but the
	 solutions are not well known.)


					John Nagle