Lets define "pointer" 
Author Message
 Lets define "pointer"


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

Tucson, AZ 85721                 noao!arizona!gudeman



Mon, 12 Apr 1993 04:05:16 GMT  
 Lets define "pointer"

Quote:

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

Quote:
> [...]
> 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.

Quote:
> [...]
> 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.)

Quote:
> [...]
> 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.

Quote:
> [...]
> 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



Mon, 12 Apr 1993 07:06:22 GMT  
 Lets define "pointer"

Quote:

>David Gudeman suggested:
>> (4) pointer: an abstration of a position in a sequence
>>     ... 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.

This one is interesting, but needs generalizing.  So let's look at
a "tree index", or even better, a graph index.  This "points" at
a component (node) of a graph, and can "move" in any direction for
which there is a field in the node (i.e. an arc from the indexed
node to another node might be described by a field name; viewing the
node as a function and applying it to the field name yields
the result consisting of the original graph, with the new node index).

At this point ( :-) there are a couple of different things we might
want to do.  Some indices will want merely to move about the graph,
looking at various nodes and the relationships among them; these
have read-access.  Others may wish to add new arcs and nodes to the
graph; these require create-access.  Still others may wish to have
the power to remove arcs and nodes, requiring destroy-access.

Perhaps the best discipline would be to create a graph attached
to an unchangeable initial index.  Then, any other index for the
graph would be declared with respect to that one, together with
its access properties.  Or perhaps not?
-----------------------------------------------------------------------------

-----------------------------------------------------------------------------
 "Who overcomes by reason sole hath overcome but half his foe..."



Mon, 12 Apr 1993 22:49:47 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Lets define "pointer"

2. Lets define "megawidget support" (LONG)

3. beginners "let"/"random" question

4. Lets define "High level" (was: Need reference for "firewall"...)

5. Definition of "let*"

6. Definition of "let*"?

7. Functions wont "let" returns

8. "let rec" in CL

9. string.join(["Tk 4.2p2", "Python 1.4", "Win32", "free"], "for")

10. define "variable" word

11. Redesigning "define interface"

12. defining "|" as or in Poplog Prolog

 

 
Powered by phpBB® Forum Software