Xref: utzoo comp.lang.misc:6124 alt.lang.cfutures:291
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!emory!gatech!mcnc!uvaarpa!murdoch!astsun7.astro.Virginia.EDU!gl8f
From: gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl)
Newsgroups: comp.lang.misc,alt.lang.cfutures
Subject: Re: Changes to C...
Message-ID: <1990Nov21.020928.13858@murdoch.acc.Virginia.EDU>
Date: 21 Nov 90 02:09:28 GMT
References: <1990Nov18.033622.1517@murdoch.acc.Virginia.EDU> <QG279:@xds13.ferranti.com> <1990Nov20.220526.24202@ingres.Ingres.COM>
Sender: news@murdoch.acc.Virginia.EDU
Organization: Department of Astronomy, University of Virginia
Lines: 51

In article <1990Nov20.220526.24202@ingres.Ingres.COM> thomasm@llama.Ingres.COM (Tom Markson) writes:

>C is great.  We all love C.  But a time comes when you say "Modifying C
>is not the answer".  

Well, if you avoid being overly general, what does C need to deal with
this example of code that messes with arrays?

foo( float *a, float *b, float *c, float *d, int n )
{
   int i;

   for( i = 0 ; i < n ; i++ ) {
      c[i] = a[i] + b[i];
      d[i] = a[i] - b[i];
   }

Now, normal C has two big problems with this code:

1. Most programmers would do strength-reduction by hand and obscure
   what is going on. This makes the compiler's job much more difficult.

2. It's difficult to analyze and prove that the store to c[i] won't
   stomp on a[i] or b[i], so they have to be re-loaded for the second
   loops statement. This case is rather simple; most of the time the
   index values are more complex.

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. And it would optionally be able to insert
bounds-checking, should I want it.

Such a change wouldn't break existing code. However, to get the
performance benefit, programmers would have to avoid obscuring arrays.
In the good old days, you had to be obscure to be fast. In the brave
new world, things are different.

Of course, I'd also want true N-dimensional arrays and a stronger
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.

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