From hirchert@ncsa.uiuc.edu  Fri Oct  6 18:17:16 1995
Received: from newton.ncsa.uiuc.edu (newton.ncsa.uiuc.edu [141.142.2.2]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id SAA14157 for <sc22wg5@dkuug.dk>; Fri, 6 Oct 1995 18:15:52 +0100
Received: from landrew.ncsa.uiuc.edu (landrew.ncsa.uiuc.edu [141.142.4.4]) by newton.ncsa.uiuc.edu (8.6.11/8.6.12) with ESMTP id MAA08757; Fri, 6 Oct 1995 12:14:01 -0500
Received: (from hirchert@localhost) by landrew.ncsa.uiuc.edu (8.6.9/8.6.9) id MAA18976; Fri, 6 Oct 1995 12:13:57 -0500
Message-Id: <199510061713.MAA18976@landrew.ncsa.uiuc.edu>
From: hirchert@ncsa.uiuc.edu (Kurt W. Hirchert)
Date: Fri, 6 Oct 1995 12:13:57 -0500
In-Reply-To: Malcolm Cohen's message of Sep 15,  9:53
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: Malcolm Cohen <malcolm@num-alg-grp.co.uk>, sc22wg5 <sc22wg5@dkuug.dk>
Subject: Re: (SC22WG5.858) Interp 179 - DO variable with POINTER attribute

In preparing my response to the 006 ballot, I took another look at Malcolm
Cohen's comments on item 000179.  I find that I agree with the specifics of
his analysis, but disagree strongly with his conclusion:

1. I agree that the "problems" identified in the questions are insufficient
   reason to prohibit the use of a pointer DO variable.

2. On the other hand, there _are_ serious problems with pointer DO variables,
   so our failure to prohibit them really was on oversight that I believe
   we wish to correct.

An example may help illustrate the real problem:

! The example program	!! A related program discussed below
INTEGER,TARGET :: J,K	! INTEGER J,K,IA(2),IP
INTEGER,POINTER :: P	! EQUIVALENCE (IA(1),J),(IA(2),K)
P=>J			! IP=1
K=11			! K=11
DO P=1,10		! DO IA(P)=1,10
   IF (P==6) P=>K	!    IF (IA(IP)==6) IP=2
   PRINT *, P		!    PRINT *, IA(IP)
END DO			! END DO
END			! END

If this program is not prohibited, the my reading of the standard is that
a. At the beginning of the loop, the iteration count is fixed at 10, the
   loop increment is fixed at 1, and the DO variable P (i.e., J) is set to 1.
b. At the completion of each of the first 5 iterations, P (i.e., J) is
   incremented, bringing P (and J) to 6.
c. At the beginning of the 6th iteration, P is associated with K, so the
   incrementation of P at the end of iterations 6 through 10 advances K
   from 11 to 16.

It seems extremely strange that is stated to run from 1 to 10 actually
runs from 1 to 5 and 11 to 15 in two different storage locations.  What
do we want to do about this example?

1. We _could_ say that this is weird but unambigous and make
   no change.  I would like to suggest that this is not acceptable.
   The "related program" in the comments above would have the same behavior
   as our example program if we allowed array elements as DO variables.
   I believe that part of the reason we do not allow the use of array
   elements is to prevent this kind of weird behavior.

2. We could do the exact analog of what was done for the "related program"
   case -- prohibit the syntactic/sematic forms that give rise to the
   change in the effective identity of the DO variable while the loop is
   running.  This is the effect of the proposed response.

3. We could allow the form but disallow the change in identity.  (In other
   words disallow the pointer assignment inside the DO loop in our example.)
   Although this would solve the problem, I find it a less acceptable
   solution because it is inconsistent with how we handled the problem
   in the "related program".  (We didn't just object to the assignment to IP,
   we objected to the use of IA(IP) in the first place.)

4. Just as the iteration count and increment are fixed at the beginning of
   the loop, independent of any changes in the variables used to compute
   those values, the identity of the DO variable could be fixed, independent
   of changes to pointers, subscripts, etc. that may have been used in
   locating it.  (In the example, J would run from 1 to 10 even though P would
   change to K.)  I believe this would be the best fix for future revisions
   (maybe even F95).  However, it seems more than I can justify to myself
   in repairing the defect in F90.  Note:
   a. If this rule is adopted, it covers the "related program" problem, too,
      so we could allow _any_ scalar integer variable to be a DO variable,
      not just those that are named.
   b. We still would need an "extra" prohibit against deallocating the
      DO variable during the execution of the loop.

-- 
Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications