🚀 go-pugleaf

gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) writes:

>What does C need? Well, if I could declare that a, b, c, and d were
>arrays of size n, the compiler would have all the info it needs to do
>a *simple* run-time check for aliasing, no matter how nasty the index
>expressions are. 

Should that look like
foo( float a[n], float b[n], float c[n], float d[n], int n )
?

Neat idea. Although it will promote the pointer/array confusion even 
further. It is already hard enough to explain to C-beginners why
`int f (int * a)' is the same as `int f (int a [])' but `extern int * b'
is not the same as `extern int b []'.

IMHO argument rewriting should be abandoned in some future version of
C (together with old-style declarations and definitions)
> And it would optionally be able to insert
>bounds-checking, should I want it.

Some compilers (e.g. Saber C) do that even now. I suppose every
pointer is really a tripel (address, lowest valid address, highest 
valid address) to them.

>Of course, I'd also want true N-dimensional arrays 

In what sense are C arrays not true n-dimensional?

>and a stronger
>library.

Me too. Especially file, process and exception handling is rather
weak. I understand that the people working on the standard wanted 
to create the greatest common denominator, but there should at least
be a set of optional functions defined for rather common actions as
*	changing the working directory,
*	executing another program,
*	disable specific exceptions (FP overflow comes to mind),
*	indexing files (IMHO one of the main reasons why COBOL is still
	successfull is the fact that it has STANDARDIZED indexed files).

Apart from that many library functions do not quite what you want
(eg. strncat) or are not consequent in their parameter ordering (The
stdio family). 

>library. This is only a first step. The major question is: would you
>end up with a simple language at the end? I hope that the end product
>would be easier to optimize, but it would certainly be bigger than
>before.

There were K&R-C compilers that ran perfectly well in 64k Text and
64k Data+Stack. GCC already needs a few megabytes.

>> The real solution
>>is to start over and design something you feel solves the problems you
>>encounter or corrects percieved deficits with C.

>I'm stuck using lots of machines, and it would be expensive for me to
>write compilers for all of them. Your real solution is great for
>research, but not so great if you're an end-user.

Extending C is not easy either. Whenever I write a C program people
come running complaining that they cannot compile it. Most compilers
called 'cc' are not C compilers nowadays, but compile the language that
was called C 10 years ago. I do not expect non-conforming compilers
to disappear for at least another 5 years (We will probably have the
next standard by then so there won't be any conforming compilers again :-)
--
|    _  | Peter J. Holzer                       | Think of it   |
| |_|_) | Technical University Vienna           | as evolution  |
| | |   | Dept. for Real-Time Systems           | in action!    |
| __/   | hp@vmars.tuwien.ac.at                 |     Tony Rand |