🚀 go-pugleaf

I cannot understand why Jim Giles wants pointers to have values which
are addresses.  The important thing about a pointer is simply that it
identifies (unambiguously) the thing to which it refers.  The only
operations on a pointer are the (a) getting the thing to which it refers;
(b) modifying the value of the thing to which it refers; (c) checking
whether two pointers refer to the same thing.  There is of course no
operation that makes the pointer point to something else (that's an
operation on a pointer-valued variable which assigns a new pointer to
it; think of an integer-valued variable - - if x has the value 3, and
the assignment x:=4 is executed, this does not assign the value 4 to
the integer 3; pointers are no different from integers in this respect
- - and yes, I have come across the broken Fortran compilers that 
allow you to assign a new value to an integer constant :-)  ).
There is no earthly reason why a pointer should support any of the 
extra operations Jim says it has to support (eg ordering), and 
certainly no reason why an implementation should be constrained to
implement it as an address. I wonder if all OO languages implement references  
to an object as addresses?  After all, a reference to an object is no more or
less than a pointer to it.  Do SQL systems implement all identifiers (keys
which are constrained to be unique) as addresses?  Well, I suppose that 
depends on what you mean by an address - - if you regard tables as being
content-addressed they do!  (PierCarlo seems to advocate that all 
identification of objects should be by content - - fair enough at some
level of description, but it's nice to have syntax which allows us to
distunguish a part of the content which can be used to identify the
object and call that part a pointer and have nice syntax for using
it as the access route to the object; and he appears to object to that).
 
Jim's arrays and indices down them are all very well, but they certainly
do not solve the aliasing issue he claims they solve; if I write 
  a[i] := a[j] the compiler does not in general know whether i and j
have different values, ie whether i and j are distinct.  Once you start
using an array of cells to implement a graph structure, with indices
used as pointers, you have exactly as much information about aliasing 
as if you used pointers instead of indices - no more, and no less;
however you as the programmer now have the problem of assigning the 
cells positions in the array, doing your own garbage-collection as
cells become free, coping with types whose values don't all occupy
the same amount of store (so a cell may occupy multiple slots in the
array) and so on; to get the language system to hide all that from you
and do it automatically, you need pointers.  It's easy to see, of course,
that all Jim's arrays do is classify pointers according to whether they
$d
that all Jim's arrays do is partition the store into a set of non-overlapping
regions - so a pointer written a[i] is known to be distinct from a
pointer written b[i]; but there is no difficulty at all in partitioning
the store and then constraining pointer-valued variables to point into
one partition or another: so if p1 is a pointer constrained to point into
region r1 and p2 is a pointer constrained to point into region r2 the
compiler knows that p1 and p2 are not aliases of each other.
 
There may be a case for low-level languages to have a pointer construct
which is constrained to be mapped as an address; for most programming
purposes, I would prefer to work in a high level language.  I claim that
any high level language (other than a single assignment language) must
have a pointer concept (although it may call it something else, and may
use search on content as the pointer resolution mechanism) since otherwise
it cannot express referential sharing and identity - - and if I have
mutable objects (ie not a single assignment language) then I must be able
to determine which refers to which so that I control whose references are
mopdified by an update (incidentally, the implementation may use accidental
sharing to optimise storage usage, and move one of the obkjects sharing
store when it changes but the other objects sharing that store don't. If
the implementation of pointer were address, as Jim insists, the representation
of the pointer to that object - and all copies of that representation -
would have to change even though the pointer has not changed, it still
references the same object. so implementations which use accidental sharing
all violate Jim's definition of pointer.)
 
Tom Thomson   [tom@nw.stl.stc.co.uk