🚀 go-pugleaf

In article  <KERS.90Oct24102535@cdollin.hpl.hp.com> kers@hplb.hpl.hp.com (Chris Dollin) writes:
]
]...I'm not sure I agree with Jim. But I'd rather disagree
]about the same thing that about two different ones, which is what I
]think David is in danger of doing...

You're taking all the fun out of it :-).  OK, I said before that this
disagreement seems to be about differing ideas of what a pointer is
(and then I promptly forgot it).  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".
You might use "address pointer" to refer to such beasts in a
programming language.  Note that C does not technically have such
pointers, although you can often pretend that it does.

Another possibility is that Jim is using the definition

(2) pointer: an abstraction of array positions that is not bounds checked

To assume no bounds checking is far too restrictive.  Of course if you
don't make this assumption then a lot of things Jim has said don't
make sense.

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.

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.

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.

In other words, you can't write "p = &x" and then start using "p" as
though it were "x", you have to write "*p".  This is probably the most
traditional definition, but if Jim has been using this definition then
his comments comparing indexes to pointers don't make sense.  As far
as I'm concerned there are both advantages and disadvantages to having
a specific dereferencing operation so I probably wouldn't argue either
way.
-- 
					David Gudeman
Department of Computer Science
The University of Arizona        gudeman@cs.arizona.edu
Tucson, AZ 85721                 noao!arizona!gudeman