🚀 go-pugleaf

From article <26788@megaron.cs.arizona.edu>, by gudeman@cs.arizona.edu (David Gudeman):
> 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).  [...]

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.

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

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

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

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

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