From hirchert@ncsa.uiuc.edu Tue Oct 10 17:40: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 RAA19428 for ; Tue, 10 Oct 1995 17:40:09 +0100 Received: from danube.ncsa.uiuc.edu (danube.ncsa.uiuc.edu [141.142.20.1]) by newton.ncsa.uiuc.edu (8.6.11/8.6.12) with ESMTP id LAA24829; Tue, 10 Oct 1995 11:39:57 -0500 Received: by danube.ncsa.uiuc.edu (8.6.9/NCSA-4.1) id LAA27412; Tue, 10 Oct 1995 11:39:57 -0500 Message-Id: <199510101639.LAA27412@danube.ncsa.uiuc.edu> From: hirchert@ncsa.uiuc.edu (Kurt W. Hirchert) Date: Tue, 10 Oct 1995 11:39:54 -0500 In-Reply-To: Richard Maine's message of Oct 6, 15:32 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Richard Maine , sc22wg5@dkuug.dk Subject: Re: (SC22WG5.894) Interp 179 - DO variable with POINTER attribute On Fri, Oct 6, 1995, at 15:32, Richard Maine wrote: >Kurt said: >> DO P=1,10 >> IF (P==6) P=>K >... > >> If this program is not prohibited,... > >By my reading it is already prohibitted. > >> 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.) > >This appears to be what the standard already does. It disallows any >redefinition of the DO variable within the loop. The pointer assignment >redefines the DO variable P. Anyway, that's how I interpreted Malcolm's >comment, and I decided I agree with it. The standard already appears >to disallow this reassignment. I read this differently -- to me this is the prohibition of "P=11". That is certainly the case it was intended to cover (and one that _needs_ to be covered). If this text is now expected to cover both cases, this needs to be clarified, because that is definitely _not_ the way _I_ would read that text. > >> 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.) > >I don't find this sufficient reason to retroactively declare formerly >legal code to now be illegal. If this consistency were important, I'd >say it was better argument for the opposite change - allowing array >elements. Note that we allow IA(IP) as a subroutine argument, even >if IP is changed within the subroutine. So this retroactive change >isn't suddenly going to make things seem consistent. This is a matter of perception. I believe there was never any intent to allow pointers as DO variables. We expanded the meaning of "variable" to include pointers late in the process and simply overlooked a place where we truly only wanted a "named variable" in the old sense. Thus, I never perceived this as something "formerly legal". I agree that allowing array elements (and other variables that are not named variables) would be the better consistent change for the future. However, since that did not reflect our intent for F90, I did not see it as an appropriate action in F90 maintenance. > >I'd say that users would be more surprised by the *IN*consistency >introduced, namely that pointers can be used everywhere except for >DO variables. Considering the trivial case where the pointer is not >reassigned within the DO loop, it seems that we are going to get >users asking "what's wrong with this?" Again, I would say this is a matter of perception -- it appears to be equally true that array elements can be used everywhere execept for DO variables or that structure components can be used everywhere except for DO variables. DO variables are very exclusionary, and I tend to see pointers (when used to access a target) as being more like array elements or structure components than like simple named scalar variables. If we had used an explicit dereferencing notation in Fortran (cf. *p in C, p^ in Pascal, p.all in Ada) instead of contextual dereferencing, the use of pointers to locate DO variables would have been syntactically excluded, and I don't think anyone would have complained that this was inconsistent. > >> b. We still would need an "extra" prohibit against deallocating the >> DO variable during the execution of the loop. > >That consitutes an undefinition of the DO variable, which is already >prohibited. As I said above, I don't see this as being clear. > >Note that the DO variable is P, not its target. P does happen to be >an alias for its target, but I don't see how that changes anything. Again, I don't see it that way. I would think that the DO variable is the entity that receives the initial value and is subsequently incremented. This would appear to be the target associated with P, not P itself. > >-- >Richard Maine >maine@altair.dfrc.nasa.gov > >-- End of except from Richard Maine (maine@altair.dfrc.nasa.gov) -- Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications