From maine@altair.dfrc.nasa.gov Tue Oct 10 18:36:20 1995 Received: from altair.dfrc.nasa.gov (altair.dfrc.nasa.gov [130.134.34.72]) by dkuug.dk (8.6.12/8.6.12) with SMTP id SAA20764 for ; Tue, 10 Oct 1995 18:36:13 +0100 Received: by altair.dfrc.nasa.gov (5.0/SMI-SVR4) id AA08071; Tue, 10 Oct 1995 10:38:02 +0800 Date: Tue, 10 Oct 1995 10:38:02 +0800 Message-Id: <9510101738.AA08071@altair.dfrc.nasa.gov> From: Richard Maine To: sc22wg5@dkuug.dk In-Reply-To: <199510101639.LAA27412@danube.ncsa.uiuc.edu> (hirchert@ncsa.uiuc.edu) Subject: Re: (SC22WG5.894) Interp 179 - DO variable with POINTER attribute content-length: 5282 >> DO P=1,10 >> IF (P==6) P=>K Kurt> If this program is not prohibited,... Rich> By my reading it is already prohibitted. ... Rich> This appears to be what the standard already does. It disallows any Rich> redefinition of the DO variable within the loop. The pointer assignment Rich> redefines the DO variable P. Anyway, that's how I interpreted Malcolm's Rich> comment, and I decided I agree with it. The standard already appears Rich> 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. Certainly it prohibits P=11, but I claim that it equally prohibits P=>K. 14.7.5(18) "Execution of a pointer assignment statement that associates a pointer with a target that is defined causes the pointer to become defined." 8.1.4.4.2 .. "the DO variable must neither be redefined nor become undefined while the DO construct is active." This seems pretty explicit to me. See also "16.6.2.2 Pointer definition status The definition status of a pointer is that of its target"... I don't see why special words about DO loops are needed to cover this particular way of becoming defined any more than speciial words for DO loops are needed to cover all of the other 18 items in 14.7.5 (plus the later corrections to 14.7.5). In fact, I disagree. It is the general statement that is what is wanted. Making a special point about item 18 just raises the question of whether it would have some different status than the other 17 ways. Kurt> This is a matter of perception. I believe there was never any intent to Kurt> allow pointers as DO variables. We expanded the meaning of "variable" Kurt> to include pointers late in the process and simply overlooked a place Kurt> where we truly only wanted a "named variable" in the old sense. Thus, Agree that this is a matter of perception (so at least we agree on something). My perception is that there is no "old sense" versus "new sense" of "named variable". Everything I read says that a pointer is a perfectly legitimate "named variable" in every sense. > 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. Agree. I wasn't proposing to make such a change. In fact I'd vote against it (because of its retroactive nature). I was just arguing against the position that we should make what I see as a retroactive change relating to pointer use because it is necessary for consistency. I'm afraid that I cannot accept arguments about what X3J3 "intended" to do in coming up with f90 as being very relevant. This relies on too many people's fallable and inconsistent memories of points that might well have not been universally agreed on in the first place. What matters now is not what X3J3 intended, but what the standard says. *ONLY* if the standard is internally inconsistent or otherwise badly broken can I accept that it is relevant to look at what X3J3 "intended." I'm not seeing anything here that is inconsistent or unworkable. Kurt> ...I tend to see pointers (when used to access a target) as Kurt> being more like array elements or structure components than like Kurt> simple named scalar variables....[discussion of what we didn't do] But it looks to me like the standard doesn't. This kind of disagreement is exactly why we should focus on what the standard says instead of what X3J3 "intended". Users are not constrained to using pointers like either Kurt or myself see them. They are constrained to using them as defined in the standard. Kurt> b. We still would need an "extra" prohibit against deallocating the Kurt> DO variable during the execution of the loop. Rich> That consitutes an undefinition of the DO variable, which is already Rich> prohibited. > As I said above, I don't see this as being clear. 14.7.6(15) "When the association status of a pointer becomes defined or disassociated(6.3), the pointer becomes undefined." See also 6.3.3.2 on "Deallocation of pointer targets". Again, this seems pretty explicit to me. Rich> Note that the DO variable is P, not its target. P does happen to be Rich> 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. Support in the standard? Why is this different from any other use of pointers. Are you saying that P=11 does not define P? (If it doesn't, then why do you say that the DO variable prohibition covers the P=11 case?). It appears to me that it defines both the target of P and (because the definition status of P is that of its target - 14.6.2.2) P itself. -- Richard Maine maine@altair.dfrc.nasa.gov