Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!yale!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Anyone want to design a languag
Message-ID: <14254@lambda.UUCP>
Date: 25 Feb 90 22:20:40 GMT
References: <5200044@m.cs.uiuc.edu>
Lines: 37

From article <5200044@m.cs.uiuc.edu>, by carroll@m.cs.uiuc.edu:
> [...]
> {Chris,Henry,Doug} correct me if I'm wrong, but I've always viewed array
> names simply as _constant_ pointers. IMHO, all of the differences between
> pointers and arrays can be understood by this model (and, of course, it
> does correspond to the underlying implementation). [...]

I'm not one of the people you specified, but I'll correct you anyway.
An array is a constant pointer with the following additional properties:

1) It's usually _not_ aliased to any other arrays in a given context.
   In fact, arrays are so rarely aliased, the compilers should assume
   they aren't (and even check to make sure) unless you explicitly state
   otherwise.  What's needed for this is a language statement which 
   say, in effect, 'the following two items might be aliased: arg1,arg2.'

2) The pointer is to a _MULTIDIMENSIONAL_ structure with different
   bounds on each dimension.  (C doesn't even get the degenerate case
   of one dimensional arrays right - it doesn't enforce the bound.  Some
   Fortran implementations also do this wrong.  But mostly, Fortran only
   ignores the bounds when you tell it to - with a '*' in the declaration,
   or when you turn off bounds checking entirely.)

3) Names of dynamically allocated arrays are not _constant_ pointers, they
   vary as the program proceeds.  Such dynamic arrays still have the first
   two properties though.

Finally, of course, any other object which is passed by reference is also
implemented as a pointer.  These other objects have different auxilliary
properties than those for arrays.  The auxilliary properties of these
should also be inforced by the implementation - at least optionally - I
don't absolutely oppose what C does, I just oppose the lack of an optional
way to make it do anything else.  In fact, the way C does things should
be the option, and the default should apply the properties I mentioned
above.

J. Giles