Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!unmvax!brainerd
From: brainerd@unmvax.unm.edu (Walt Brainerd)
Newsgroups: comp.lang.fortran
Subject: Re: dpANS Fortran 8x
Summary: You can point to noncontiguous storage
Message-ID: <135@unmvax.unm.edu>
Date: 13 Jun 89 02:25:43 GMT
References: <2716@elxsi.UUCP> <13934@lanl.gov>
Distribution: usa
Organization: University of New Mexico at Albuquerque
Lines: 46

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.  The target must not involve a _vector_
subscript, but may be, for example, a row of an array, which, if stored
in the traditional way, will not be in contiguous storage.  I.e.,
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

As Scott Lamson pointed out, this isn't legal unless A has the target attribute.

The following 2 paragraphs do NOT refer to Jile's article:

Someone else wanted the syntax to be something like
POINTER TO, REAL :: P1, P2
but statements of this form are simply extensions of the F77 type statements,
which all begin with the name of a type and may be followed by various
attribute like DIMENSION, TARGET, POINTER, SAVE, PARAMETER, etc.,
so it wouldn't be good to change the syntax for just one of them.

The reason the default is to dereference pointers in most contexts
is that it is believed that a large majority of pointer use is
to reference its target and the default should be the case that
is most frequent.  The down side is perhaps that other languages
do it the other way (every once in a while, it's done right in Fortran!).

> The only _new_ functionality provided by pointers is the ability to
> define recursive data structures.  But this capability would have been
> easier to define and implement by _really_ allowing recursive structure
> (derived type) declarations.
> 
I certainly agree with this.
True recursive data structures were proposed to X3J3,
but this idea is much too radical for the current membership.
It's not the Fortran way (too elegant!).