Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!ames!hc!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: dpANS Fortran 8x
Message-ID: <13941@lanl.gov>
Date: 16 Jun 89 23:35:38 GMT
References: <150@unmvax.unm.edu>
Distribution: usa
Organization: Los Alamos National Laboratory
Lines: 35

From article <150@unmvax.unm.edu>, by brainerd@unmvax.unm.edu (Walt Brainerd):
> [...]
> If you think of a pointer as just an ADDRESS
> (possibly one that can be incremented and multiplied by 7, etc.),
> (this sort of thing certainly has occurred in Fortran implementions)
> then the proposed Fortran pointers do not fit with that model.
> [...

That is _exactly_ the model of pointers I have in mind (with the addition of
typed pointers so static type checking of the pointee is possible).

> ...]
> If you think of a pointer as a POINTER (pointing to, referencing, or aliasing
> another object), then all uses of pointers in the proposed Fortran standard
> fit within this notion (including "tradidional" uses of pointers
> to implement linked lists and other data structures).
> [...

I have _never_ seen or heard of a language with this model of pointers.
Could you give me a reference to such a thing?  I would oppose this kind
of junk in any case, but it would be interesting to see some language in
which people have direct experience with such a badly thought out feature.
(I think this whole thing is a clever form of revenge for the bad public
review last time.)

> ...]
> In summary, the uses and description of pointers are consistent as proposed;
> it may not fit some notions of what people have thought of as pointers.

In summary, recursive data structures and array section aliasing are two
_separate_ and _distinct_ activities.  In fact, it's hard to imagine using
the same pointer to do both of these in the same code!  (And, if this does
happen, it's probably an unintended and hard to find error.)  As a result,
they should have separate and distinct implementation in a programming
language - preferably _without_ using pointers for either feature.