Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!ncar!noao!arizona!gudeman
From: gudeman@cs.arizona.edu (David Gudeman)
Newsgroups: comp.lang.misc
Subject: Re: Lets define "pointer"
Message-ID: <26788@megaron.cs.arizona.edu>
Date: 25 Oct 90 07:44:07 GMT
Organization: U of Arizona CS Dept, Tucson
Lines: 97

In article  <3808@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
]From article <26767@megaron.cs.arizona.edu>, by gudeman@cs.arizona.edu (David Gudeman):
]>
]> (1) pointer: a low-level abstraction of a machine address
]
]...  I can't agree with you that this definition is too
]specific though...

But there are great differences between machine addresses and the
pointers of most programming languages.  Pointers, for example are
generally typed, and can legally only point at a certain set of
objects (though some languages/implementations don't provide much
security on this).  Also, there is a restricted set of basic
operations that produce new pointers (address-of and allocation).  You
can't make up arbitrary integers and expect them to be legal pointers.
And in languages with pointer arithmetic, there is no guarantee that
memory is laid out in any given manner.  That is, if you declare two
arrays {int A1[5], A2[5]; ...} you have no guarantee that A1[7] is a
reference to A2.  Pointers can't be true memory addresses unless the
programmer knows something about the way memory is laid out.

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

Not quite.  Everyone assumed that pointer arithmetic was legal and
predictable as long as the addresses involved were legal unsigned
longs.  But no one ever (to my knowledge) thought that the language
allowed the _dereferencing_ of arbitrary pointers in any portable
manner.

]> (3) pointer: a reference to a mutable object
]
]This is what I've been refering to as variables which are associated
]with each other through the "aliased" attribute.

I had something a bit more abstract in mind.  What happens when you do
something like this

  x = new_object;
  y = x;
  change_object(y);

where the function call "change_object" has some side-effect on y?  At
the abstract level we can say that the object referenced by x is
mutable, in which case the change to y causes an identical change in
x.  Or we can say the object is immutable, in which case it can't
actually be "changed", you can only assign a different object to y,
and x remains the same.  For example in Icon, strings are immutable
and lists are mutable.  Therefore after the code sequence

  s1 := "abc"; s2 := s1; s2[2] := "x"
  l1 := [1,2,3]; l2 := l1; l2[2] := 0

you have s1 = "abc", s2 = "axc", l1 = l2 = [1,0,3].  This feature
cannot be completely described with either aliasing or pointers,
because two immutable objects may alias either other.  It is also
possible to imagine a situation where two data objects do not overlap
in memory but are still connected as identical mutable objects (for
example in an object distributed over a network).

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

Like anything else, it can be implemented on top of other
abstractions.  However without direct language support I doubt many
people would use it, they would just fake it with indexes.  This is
similar to the situation in C where you need an explicit "break" in
switch statements.  How many people define a macro

#define cs break; case

and how many just keep writing out the "break" everywhere?

] "aliased"
]variables (and _only_ for those) a "shallow copy" assignment operator
]is all that is needed:
]      x = 5             !normal "deep copy" assignment
]      y <- x            !"shallow copy" assignment
]      z = y             !normal "deep copy" assignment

And presumably:
       x = 6		!the values of both y and x get changed to 6

Well, I said I wouldn't argue either way, but I may as well play
Devil's Advocate.  This is syntactically nicer and (I believe) less
confusing than pointers, but you have lost the idea of references as
first-class objects.  That is, you cannot pass references to
procedures or get them returned from procedures.  The only things you
can do with references is what the language specifically provides for.
-- 
					David Gudeman
Department of Computer Science
The University of Arizona        gudeman@cs.arizona.edu
Tucson, AZ 85721                 noao!arizona!gudeman