🚀 go-pugleaf

In article <1990Oct28.015733.9181@murdoch.acc.Virginia.EDU>, gl8f@astsun9.astro.Virginia.EDU (Greg Lindahl) writes:
> Actually, it just shows that we're talking past each other most of the
> time. Here's a practical example where the boundedness of array
> references allows you to easily generate better code:
> 
>      a[i] = b[i] + c[i]             *a = *b + *c;
>      d[i] = b[i] / 2.               *d = *b / 2.
> 
> For the array version, the compiler can check to see if a and b
> overlap, and if not it doesn't have to load b[i] twice. For the
> pointer version, the compiler has to figure out what a, b, c, and d
> point at, if it even bothers at all.

Yes, *sigh* we're all talking past each other.
	THIS IS NOT AN INTRINSIC PROPERTY OF POINTERS;
	it is a property of the programming language *C*.

I haven't my Euclid manual handy, so I'll use Pascal syntax and
the Euclid idea:
	var
	    az: zone of real;
	    bz: zone of real;
	    ap, dp: ^az;
	    bp, cp: ^bz;
	begin
	    new(ap);	(* allocates from zone az only *)
	    ...
	    ap^ := bp^ + cp^;	(* this assignment CANNOT change bp^ or cp^ *)
	    dp^ := bp^/2;	(* neither can this *)	    
	    ...

The fact that C pointers are not statically associated with
separate zones is no more a fundamental property of pointers
than the fact that PL/I pointers are not statically associated
with a type.

To put this into C terms, suppose we introduce a new type
constructor "pointer into named array".  Here's how the example
might look:

	float a[N], b[N], c[N], d[N];
	float *[a] ap, *[b] bp, *[c] cp, *[d] dp;
	... ap = ... bp = ... dp = ...
	*ap = *bp + *cp;	/* can ONLY change a[] and *ap */
	*dp = *bp/2;		/* can ONLY change d[] and *dp */

This would be an upwards compatible extension C, just as 'const' was.
-- 
The problem about real life is that moving one's knight to QB3
may always be replied to with a lob across the net.  --Alasdair Macintyre.