Path: utzoo!attcan!uunet!wuarchive!zaphod.mps.ohio-state.edu!rpi!uupsi!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Lets define "pointer"
Message-ID: <3808@lanl.gov>
Date: 24 Oct 90 23:06:22 GMT
References: <26767@megaron.cs.arizona.edu>
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 136

From article <26767@megaron.cs.arizona.edu>, by gudeman@cs.arizona.edu (David Gudeman):
>
> [...]                                   If Jim is using the definition
> 
> (1) pointer: a low-level abstraction of a machine address
> 
> then most of his points are unarguable.  Such a low-level construct is
> bound to be the source of hard-to-find bugs, and is bound to cause
> problems for an optimizing compiler.  I think this is far too specific
> a definition, and the idea is already covered by the term "address".

This is indeed the definition of the object I call "pointer".  I'm
gratified that you consider most of my points to be unarguable in
this context.  I can't agree with you that this definition is too
specific though.  In fact, for very low-level applications, this is
the pointer's optimal interpretation.

> [...]
> Another possibility is that Jim is using the definition
> 
> (2) pointer: an abstraction of array positions that is not bounds checked

First, you left out the fact that pointers are only similar in this
way to *one*dimensional* arrays.  My definition of arrays requires
more than boundedness of indexing - it requires the possibility
of multiple orthogonal index sets.

Note, only C pointers have the ability to index.  No other popular
language does (unless it can trace its design to C).  So, indexing
is an extension - it has no place in the fundamental definition
of what pointers are.

Note: as a practical matter, everyone assumed that C pointer arithmetic
_was_ unbounded until the debate about the ANSI proposed standard a
few years back.  To be sure, K&R (the closest thing to a language
definition that C had before the standard) did not define what pointer
arithmetic beyond the bounds of individually allocated objects meant.
But, everyone uniformly seemed to assume that it was valid address
calculation.  It is certainly one of the most common _non-standard_
practices today.

> [...]
> Others are using the definition
> 
> (3) pointer: a reference to a mutable object
>
> That is, if you have X and Y, and something done to X can cause Y to
> change, X and Y must be or contain pointers.  I think this is far too
> general a definition, especially since the well-known term "mutable
> object" already describes the situation.

This is what I've been refering to as variables which are associated
with each other through the "aliased" attribute.  To be sure, pointer
(those raw address things) can be used to implement this feature, but
pointers aren't sufficiently controllable.  (Or, if you make them
sufficiently controllable, then they won't be any different from the
"aliased" attribute I recommend - at least, that is my contention.)

> [...]
> I have been using the definition
> 
> (4) pointer: an abstration of a position in a sequence
> 
> Now I'll admit that this is non-standard and that I never completely
> spelled out my assumptions.  In the future I'll try to use the term
> "sequence pointer" to refer to these.  In particular, I was _not_
> arguing that there is no need for recursive data structures or for a
> better way to reference dynamic storage (both done with pointers in
> C).  My argument was that pointer(4) is a useful abstraction.

From your previous posting of this idea, I can't see that it requires
more than the data structures that I've been hawking.  However, I wouldn't
call this object a "pointer" - it is clearly a "list index" or some such
thing.  I _would_ like to know more about this abstraction though.
Even if I don't decide it needs direct implementation in a language,
it could be a good example of the types of things that need to be
supported.

> [...]
> Another possibility for the definition that Jim has been using:
> 
> (5) pointer: an abstraction of a reference (to a mutable object) that
>              has a specific dereferencing operation.

To be sure, a pointer (that raw address thing) does need a dereferencing
operator in order to retrieve specific objects.  This need is due to the
properties of the pointer.  It is most certainly _not_ the definition of a
pointer.  I _have_ argued that dereferencing and the "address-of" operator
would be unnecessary if pointers did not exist.  Instead, for "aliased"
variables (and _only_ for those) a "shallow copy" assignment operator
is all that is needed:

      aliased integer :: x, y
      integer :: z

      x = 5             !normal "deep copy" assignment
			!the _value_ of X is replaced with 5
			!if the _reference_ part of X is nil,
			!(a possibility for "aliased" variables)
			!it is allocated first.

      y <- x            !"shallow copy" assignment
			!the _reference_ part of Y is replaced with
			!a copy of the _reference_ part of X
			!the two variables are now _really_ aliased
			!the attribute merely declared they were _allowed_
			!to be

      z = y             !normal "deep copy" assignment
			!the value of Z is replaced by that of Y (now 5)

      z <- y            !ILLEGAL!  Z has not been declared aliased with Y

Note that in all contexts, the variables X, Y, and Z have the usual
meaning of integer variables - _except_ when the "shallow copy"
operator is used.  In that case, it is the _reference_ part of the
variable's meaning that is used or altered.  No "dereference"
operator is needed since the value is accessible just like any
other integer variable.

Consider the degree of control here:  X and Y may be aliased to each
other (or not), but they can _never_ be aliased to anything else in
this context.  If they are passed to some other context (through
procedure arguments or as global variables) the new context would
_also_ have to declare them as "aliased".  This last constraint
can be verified at load time.  This means that the compiler is
_always_ informed about which variables might be aliased and which
are certainly never aliased - result: more efficient code.  The user
is also aware easily of aliasing possibilities - result: easier
debugging.

Note: the "shallow copy" operator requires an "l-value" on _both_
the left- and the right-hand sides (very much like pointer assignment,
which is what this replaces).

J. Giles