Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!indri!unmvax!pprg.unm.edu!hc!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.fortran
Subject: Re: dpANS Fortran 8x
Message-ID: <13949@lanl.gov>
Date: 20 Jun 89 10:08:26 GMT
References: <1536@uw-entropy.ms.washington.edu>
Distribution: usa
Organization: Los Alamos National Laboratory
Lines: 76

From article <1536@uw-entropy.ms.washington.edu>, by charlie@mica.stat.washington.edu (Charlie Geyer):
> [...]
> The question to you now is: Why do you think this kind of abstraction is
> wrong and what kind of abstraction -- raw addresses aren't -- is the 
> right one?

I have already answered this is previous postings.  Pointers are a bad idea
because they put too much functionality into a single construct.  In this
regard they are rather like GOTOs (in fact, when comparing control flow
with data structuring, GOTOs are isomorphic to pointers).  To be sure, you
can code any control flow you want using only conditional jumps (even
procedure calls) - but do you _want_ to?  The reason we have IF-THEN-ELSE,
DO, CASE, etc. is to provide the specific functionality required and no more.
This simplifies the task of both the programmer and the compiler in producing
correct and efficient code.

Now, clearly you can define any data structure you want using pointers.
But, again, do you want to?  Consider the following examples:

      Old Fortran 8x                        New Fortran 8x

      REAL, RANGE :: A(100)                 REAL TARGET:: A(100),B(98)
      REAL, RANGE :: B(98)                  REAL POINTER :: X(:)
      ...                                   ...
      SET RANGE (A(2:99))                   X => A(2:99)
      ...                                   ...
100   B=A                             100   B=X
      ...                                   ...
      
(I don't have the 8x proposals with me, so the syntax here may be a
little off.  But the idea is clear.)

In both these examples, the assignment at label 100 can be done at
optimal speed since the objects are not aliased.  But the question
is: can your compiler recognize that B is not aliased to the other? 
For the old 8x proposal, even a really dumb compiler can tell the
assignment is safe.  The reason is that RANGE _CAN'T_ cause aliasing!
RANGE simply restricts the active elements of the underlying array.
In the new 8x proposal, the compiler must do some flow control to
make sure that no pointer assignment to X can have caused aliasing
to B.  If the compiler is not that smart, it must generate code
which assumes that B and X are aliased.

Consider next a case where aliasing occurs:

      Old Fortran 8x                        New Fortran 8x

      REAL A(100),B(98)                     REAL TARGET :: A(100),B(98)
      ...                                   REAL POINTER :: X(:)
      ...                                   ...
      IDENTIFY (X(I)=A(I+1),I=1,98)         X => A(2:99)
      ...                                   ...
      CALL SUB1(X,B)                        CALL SUB1(X,B)
      ...                                   ...
100   B=X                             100   B=X
      ...                                   ...

Once again. the assignment at label 100 is safe, B is not aliased to X.
The question, again, is: can your compiler detect that it's safe to
optimize the assignment?  By the standards of the first example, the
compiler must be reasonably smart in both proposals.  Still, flow
analysis will detect that it's safe for the old 8x proposal.  In the
new proposal, the compiler can't tell whether X is aliased to B without
doing interprocedural analysis - the subroutine call _COULD_ have
reassigned X.

The old proposal gave the programmer the tools to define array sections
as required - but _NOTHING_ else.  Neither the programmer nor the compiler
needs to take into account functionality that isn't needed.

I think that RANGE and IDENTIFY are _MUCH_ better at array sectioning
than the present POINTER proposal is.  For recursive data structures
I think that they should be provided as just that: recursive structures
without explicit pointers required.  Aside from these, I can't think
of any other need for pointers.  I think that Fortran should not have
pointers introduced.