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



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

Tucson, AZ 85721                 noao!arizona!gudeman



Mon, 12 Apr 1993 15:44:07 GMT  
 Lets define "pointer"

Quote:


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

Quite so.  In C, this constraint is unenforceable without expensive
run-time tests. (You can cast to (void *) legally.  Then you can
cast to (anything *) later.  Nothing but a tag on the pointer value
and a run-time test could detect this in the general case.)

In Pascal-like languages (including the one I propose - which
differs only in syntax and in placing much stricter bounds on the
range of aliasing allowed) the underlying type is indeed
adequately constrained.  A properly constructed compiler/loader
environment can insure that pointers always are used with the
proper type.  You are correct that this is an important property.

Quote:
> [...]               Also, there is a restricted set of basic
> operations that produce new pointers (address-of and allocation).  [...]

The set of operations defined on _any_ data type in a computer
language is restricted.  I know of no language which contains all
the normal mathematically defined _integer_ functions.  Pointers
don't fare any better.  In fact, there is no need for _any_
address operation but assignment (what I call "shallow copy")
in a high level language.  For a _very_ low level language, the
address calculations should be as unrestricted as possible.

Either way, the pointer itself is an address.  That's what the
_reference_ part of a variable which the "shallow copy" operator
effects is.  Putting constraints on the allowed operations on
addresses doesn't change what they are.

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

Well, I don't know about whether people expected it to be portable
or not.  The fact remains that pointing about like that _is_ a
common occurrence in C code that I've been unfortunate enough to
have had contact with.  Some of this is 'professionally' written
code with wide distribution.  I'm told that this particular problem
was among the many which slowed the porting of much 'standard'
UNIX software to UNICOS on the Cray.

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

See below.

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

Yes.

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

Huh?  A variable with the "aliased" attribute can be passed to a
procedure.  If it is the object of a "shallow copy" operation in
the procedure, the resulting new _reference_ part of the variable
will be returned just like any change in the _value_ part of the
variable would have been.  Why would you not expect this to be the
case?  As I have said, the "aliased" attribute is semantically
_identical_ to the pointers in Pascal and similar languages (except
for the more stringent bounds on aliasing).  If Pascal pointers are
"first class" objects - then so are "aliased" variables.

J. Giles



Tue, 13 Apr 1993 04:31:42 GMT  
 
 [ 2 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