"C" wish list.

[Crispin Goswell]

In article <335 at graffiti.UUCP> peter at graffiti.UUCP (Peter da Silva) writes:
>what features would you add to 'C' if you were god or some other moral
>equivalent of Dennis Ritchie?
Are you listening, Dennis Ritchie?
>
>Here are some wishes that the recent discussions have woken in me:
>
>	1. Extend the syntax of bit-fields to ordinary numbers
>	2. Allow auto aggregate initialisations
>	3. Allow constant aggregates
>	4. Allow true block structuring
>	5. Add some real programmability to cpp.

I'm one of those people who think that structs should be first class objects
in C. Doing this properly could probably be done fairly easily. I don't
think array aggregates could be added and remain in the spirit of the language,
because of the intimate relationship between pointers and arrays. This would
seem to require a non-linear address space.

There is a language called C++ which is a (nearly) upward compatible superset
of C, which provides some features that are on my wish list, but few of those
you have mentioned. I don't have a reference to hand, but it is fairly well
known.
	My wish list has things to remove from C, so I could not really call
	the result 'C', in any form. I largely agree with your list, though
	I'm not sure what 5. refers to. Generics? 
	
	1. I'm not a fan of cpp.
	   I believe the features it provides should be part of the language
	   proper.  C++ provides constants, and inline functions, which should
	   remove the need for macros. I like these, though the circumstances
	   under which it is possible to use inline functions in C++ are
	   unfortunate, since it is a direct result of the way separate
	   compilation is usually achieved on UNIX. The latter leaves much to
	   be desired.
	   
	2. I'm not in favour of #ifdef. I believe that machine specifics 
	   should be in separate files, and my programming methodology usually
	   makes this easy to achieve.

	3. Make static the default for global values, rather than extern (C++
	   does this).
	
	4. Remove the default declaration of names to int. This is reminiscent
	   of FORTRAN, and causes many problems. C++ doesn't do this,
	   presumably because it breaks too many programs. There are many
	   things that lint(1) checks which belong in the compiler. C++ does
	   cross-'module' type checking better than C. The ANSI C standard adds
	   checking of function arguments, I'm told. I haven't read it yet.

	5. There are various parts of the syntax that I don't like:
		1. = for assignment, bring back :=
		2. ;'s as statement terminators, I prefer the algol statement
		   separator.
		3. I don't like anonymous blocks. I like IF ... FI. I think
		   Algol68 got this right. switch is not nice, but neither
		   is Algol68's case.
	
	6. Nameless functions would be useful. It is already possible to pass
	   function pointers around (this business about taking the address of
	   a function needs to be tidied up. Does anyone know what ANSI says
	   about this?). It would be useful to make functions first class
	   objects as well, so that one could have an aggregate of function
	   bodies with no names. There are probably difficulties of scope with
	   this, which may make it impractical for a language like C.
	
	7. C needs modules: either the current method of treating a file as a
	   module needs to be formalised, or some module structure should be
	   added. I'm not sure what is the best answer to this one.

	8. There has been much discussion recently about ints, shorts and the
	   like. I hate to say this, but Ada seems to have the right sort of
	   facility. Perhaps it could be simplified so that mortals can use it.
	   Keeping the size of a number range in the abstract is probably good,
	   and people who *know* they want a particular size for a particular
	   dirty application can choose the range which will get them the size
	   they want. There are separate issues regarding the use of shorts and
	   ints: speed vs. space and fixed format data. Speed vs. space should
	   probably be achieved with Compiler directives as it should not
	   affect the semantics of a program. Fixed format data should probably
	   be handled with user defined types created specially for the
	   purpose.

I hope it is clear to everyone reading, that I am not suggesting these changes
be made to C. They would constitute a new language entirely, which is not
sufficiently different to be worth designing at this stage. I am interested
in comments however, since I may one day sit down and do this. I'm dissatisfied
with C, but C++ doesn't fill some of the gaps I would like filled.

	Crispin Goswell.