Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!pprg.unm.edu!hc!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: dpANS Fortran 8x
Message-ID: <13937@lanl.gov>
Date: 13 Jun 89 22:56:46 GMT
References: <135@unmvax.unm.edu>
Distribution: usa
Organization: Los Alamos National Laboratory
Lines: 52

From article <135@unmvax.unm.edu>, by brainerd@unmvax.unm.edu (Walt Brainerd):
> In article <13934@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:
>> The new pointers _DO_NOT_ provide the functionality of the deleted features.
>> Pointers cannot be used to implement either the RANGE attribute or the
>> IDENTIFY statement.  This is because pointers can only alias _contiguous_
>> memory locations - which is an insignificant subset of the capabilities
>> of the two features that have been removed.
> I have just received the latest version of the X3J3 draft
> and I see nothing that restricts a pointer target to an object
> that is in contiguous storage. [... 

I also have seen the June release of the standard.  I see nothing that
_requires_ pointers to be anything but an address with a type attribution.
At present, the semantics of pointer variables are not adequately described
in the proposals.  If Brainerd is correct, however, then I am more against
pointers than I was before - the committee is compounding too many _separate_
functionalities into a single construct.  

> ...] unless I am missing something, the following is legal:
> 
> REAL, DIMENSION (100, 100), TARGET :: A
> REAL, DIMENSION (100), POINTER :: P
>    . . .
> P => A (50, :)  ! P IS AN ALIAS FOR ROW 50 OF A

In order to implement this, the pointer must actually be (what used to be
called) a 'dope vector'.  This is an outgrowth of that overloading I
mentioned - by putting this functionality into the POINTER they are
no longer pointers!  Instead of the above, why not have:

REAL, DIMENSION (100, 100) :: A
REAL, DIMENSION (100), ALIAS :: P

P <=> A (50, :)  ! P IS AN ALIAS FOR ROW 50 OF A

Now, P really is an alias for A(50, :) and every use of P should be treated
as if A(50, :) had been written (at least until the next assignment to P).
This still doesn't allow the full functionality of INTENTIFY, but it doesn't
overload pointers either.  Note: the above works only if P is not allowed
as a common variable, thus making the fact that A has been aliased locally
detectable - One of the problems with using pointers for this is that
non-local pointers must be assumed by the compiler to be aliased to all
other pointers and all TARGET variables, nothing more can be statically
determined.

Traditionally, pointers in low-level languages have served many purposes.
In a high-level language, pointers have nearly _no_ useful roles.  If
Fortran had an explicit aliasing capability (IDENTIFY was good), plus
a dynamic memory allocation mechanism (ALLOCATABLE is good), plus a
recursive data structuring capability, then pointers would not be needed
at all.  I am certainly against compounding all these separate features
into one syntactic form.