Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!hao!husc6!linus!philabs!pwa-b!mmintl!franka
From: franka@mmintl.UUCP (Frank Adams)
Newsgroups: comp.lang.c
Subject: Re: The D Programming Language
Message-ID: <2731@mmintl.UUCP>
Date: 23 Feb 88 21:23:40 GMT
References: <11702@brl-adm.ARPA> <243@eagle_snax.UUCP> <2245@geac.UUCP> <2718@mmintl.UUCP> <2327@umd5.umd.edu>
Reply-To: franka@mmintl.UUCP (Frank Adams)
Organization: Multimate International, E. Hartford, CT.
Lines: 67

In article <2327@umd5.umd.edu> chris@trantor.umd.edu (Chris Torek) writes:
|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.
|
|Oddly enough, I have been considering the same sort of thing myself.  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).

Agreed.

|>I would also like to do away with having control statements control single
|>statements.  ... "if (foo) stmt1; stmt2; end;" ...
|>"for <stmts| while (<exp|) next <stmts| do <stmts| end;" ...
|>"loop <stmts| while (<exp|) <stmts| end;".
|
|I disagree with the details,

I would like to see other proposals.

|[may prefer 'endif' to 'end', but has doubts]

I debated whether to put in 'endif', etc., or 'end' in the above, and
finally opted for the shorter form.  Ask me on another day and you might get
a different answer.

|A general aggregate constructor is necessary.

Any suggestions on how to do this?

|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.

I don't think we should *require* this.  The language should still have a
place for the fast and cheap compiler, which still produces reasonably good
code.

| - 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).

Yes, but I would not put the object oriented stuff into D.  For that, you
get D++.

Overloaded functions are fine, though.

|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.

Definitely.  Library development should go on in parallel to the language
development, and whatever flexibility the language provides should be
reflected in the library.
-- 

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Ashton-Tate          52 Oakland Ave North         E. Hartford, CT 06108