Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!snorkelwacker!usc!zaphod.mps.ohio-state.edu!rpi!uupsi!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Pointers as 3-tuples (Re: JLG's flogging of horses (was Re: Relationship between C and C++))
Message-ID: <14313@lambda.UUCP>
Date: 9 Apr 90 06:37:34 GMT
References: <ZZR2:M4xds13@ficc.uu.net>
Lines: 31

From article <ZZR2:M4xds13@ficc.uu.net>, by peter@ficc.uu.net (Peter da Silva):
> [...]
> Just think of *A as a shorthand for A[0].

Very good!  Now we've got grounds for some sort of agreement.  If you will
review my preceeding articles on this subject, you will find that I have
said almost exactly this.  In fact, I will repeat my earlier statement:
except for aliasing and bounds checking, pointer arithmetic is semantically
IDENTICAL to one dimensional array indexing.  Under your proposed 3-tuple
idea, the distinction between pointers and arrays is further narrowed. In
fact, because of the way you've constructed it, the two concepts are now
nearly identical since the aliasing can only be within the _same_ bounded
object.  But this also can be done with arrays (ie. A[i] and A[j] for 
unknown i and j are assumed aliased).  So, since there is now _NO_
remaining difference between the two concepts, why have both in the
language?  Arrays are the more flexible (since they can be multidimensional).
Further, the array syntax tends to be more legible.

So, I will just think of A[0] as a legible (therefore preferable) substitute
for *A.

Note that the above argument only applies to the issue of pointer _arithmetic_.
For recursive data structures, either pointers or some other mechanism is
still required.  (Actually, even recursive data structures may be implemented
with arrays, but it is less elegant in the general case.)  I prefer a more
direct syntax for recursive data structures than to go through user-visable
pointers - but that's another issue.  The point of this discussion is
that pointers are not, and should not be treated, as a useful method of
implementing arrays.

J. Giles