Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!yale!husc6!mit-eddie!uw-beaver!cornell!rochester!PT.CS.CMU.EDU!IUS1.CS.CMU.EDU!edw
From: edw@IUS1.CS.CMU.EDU (Eddie Wyatt)
Newsgroups: comp.lang.c
Subject: Re: The D Programming Language
Message-ID: <915@PT.CS.CMU.EDU>
Date: 20 Feb 88 17:54:46 GMT
References: <11702@brl-adm.ARPA> <243@eagle_snax.UUCP> <2245@geac.UUCP> <2327@umd5.umd.edu>
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 57


> >Another shortcoming to be fixed is the automatic fallthrough for select
> >statements.
> 
> agree

   However, some means of fall through should be provided, BUT it should be
explicitly expressed.


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

  Not probably, definately we still need the pre-processor.  The
pre-processor supports a limited form of types as parameters. 
Example:

	#define alloc(type)		((type *) malloc(sizeof(type)))

Unless you are going to  support some other form of polymorphism that
will allow the above to be expressed, leave in the  pre-processor.

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

  Unless you require function prototypes to be within scope, null
will not do you much good.

> 
> I think the following are important considerations:
> 
>  - the language should be made as small as possible, but no smaller.

    I agree, a very very very important point.

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

    Which brings up a question, what happens to the asm statement then.
If you have the write you code such that you have no idea
where variables are stored, how can you reliable use assemble statement
that play with storage.  I think the conclusion will be trash asm.


-- 

Eddie Wyatt 				e-mail: edw@ius1.cs.cmu.edu