From j.s.morgan@liverpool.ac.uk Wed Mar 29 12:07:11 2000 Received: from mailhub2.liv.ac.uk (mailhub2.liv.ac.uk [138.253.100.95]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id MAA20628 for ; Wed, 29 Mar 2000 12:07:06 +0200 (CEST) (envelope-from j.s.morgan@liverpool.ac.uk) Received: from pcmail1.liv.ac.uk ([138.253.252.13]) by mailhub2.liv.ac.uk with esmtp (Exim 2.12 #1) id 12aFMx-0003K6-00; Wed, 29 Mar 2000 11:06:35 +0100 Received: from [138.253.102.198] (helo=pc102198.liv.ac.uk) by pcmail1.liv.ac.uk with smtp (Exim 2.12 #1) id 12aFKM-0004lR-00; Wed, 29 Mar 2000 11:03:54 +0100 From: Steve Morgan Reply-To: J.S.Morgan@liverpool.ac.uk To: John Reid Cc: SC22WG5@dkuug.dk Subject: Re: (SC22WG5.1732) Interpretation 001 In-Reply-To: <200003281008.MAA15751@dkuug.dk> Message-ID: Date: Wed, 29 Mar 2000 11:03:54 +0100 (GMT Daylight Time) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.5 Build (43) X-Authentication: IMSP MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII John, I've looked at 001 and (not surprisingly) agree with Henry's analysis. However, I tried the following code on 4 compilers (Salford, NAS, Sun's F90 and NAG's F90) and they all assume that the variable j in the implied DO creates the variable j. Each gives an error message for the INTEGER::j statement indicating that j has already been defined in the scope i.e. it has been exported from the module. Module mod1 INTEGER :: A(10)=(/(j,j=1,10)/) End Module mod1 Program prog1 USE mod1 INTEGER :: j PRINT *, "j = ",j End Program The text in 14.1.3 should be enough to indicate that j IS NOT visible outside its containing statement but clearly at least 4 compiler vendors seem to have mis-interpreted the standard (IMHO). [From the email discussions it seems that at least 6 other Fortran experts agree (Adams, Dedo, Zongarro,Bleikamp, Schonfelder,Oglesby)] Although I don't think it should be necessary, the above makes me think that it may be desirable to include/modify some text in the standard to make the scoping rules more explicit. Henry's analysis rightly points to the significance of the words "would have if it were"(14.1.3) and "If" in 281:12-14. One could argue that this is rather loose usage considering the importance of the concept. I'm happy to attempt a re-write but thought I'd "fly" it first in case I'm going over old ground (I haven't been tracking the mailing lists very carefully for some time). I'd be interested to know whether other compilers also make the wrong (IMHO) interpretation. If we find that most compilers have the wrong interpretation then it might be a case of struggling to shut the stable door after the horse has bolted. Cheers, Steve. On Tue, 28 Mar 2000 10:44:04 +0100 (BST) John Reid wrote: > Date: 28th March 2000 > To: J3 > From: John Reid > Subject: Interpretation 001 > > Here are drafts for the ANSWER and EDITS sections of 001. They are > based on the email from Henry Zongaro. Also, I propose that the > addendum be removed. For your convenience, the current 001 is > attached. > > ANSWER: > The implied-DO variable is not visible to the using program. > 14.1.3 Statement Entities states, in part, that > > The name of a variable that appears as the DO variable of an > implied-DO in a DATA statement or an array constructor has a scope > of the implied-DO list. It has the type and type parameter that it > would have if it were the name of a variable in the scoping unit > that includes the DATA statement or array constructor and this type > must be integer. > > The words "would have if it were" were intended to convey > the idea that the existence of an array constructor or data implied-DO > variable does not actually cause an associated variable in the scoping unit > to come into existence. > > Also, the following text appears in the same section (281:12-14): > > If the name of a global or local entity accessible in the scoping unit of > a statement is the same as the name of a statement entity in that > statement, the name is interpreted within the scope of the statement > entity as that of the statement entity. > > The word "If" here implies that there need not be any such > global or local entity with the same name as that of the statement entity. > > EDITS: None. > > > ------------------------------------------------------------------------------- > > NUMBER: 000001 > TITLE: Visibility of a data object with statement scope > KEYWORDS: visibility, data object, statement scope, scope > DEFECT TYPE: Interpretation > STATUS: X3J3 consideration in progress > > QUESTION: > > Part 1: > > Consider the following program: > > MODULE mod > INTEGER, PARAMETER :: jmin(1:10) = (/ (i, i = 1, 10) /) > END MODULE > > > PROGRAM main > USE mod > INTEGER :: i > > DO i = 1, 10 > PRINT *, 'jmin(i) = ', jmin(i) > END DO > > END PROGRAM > > Some Fortran compilers consider the implied-DO variable I used in the module to > be visible to program units using the module and some Fortran compilers do not > consider the I to be visible to using program units. > > Is an entity with statement scope in the specification part of a module visible > to a program unit using the module and accessing the public data of the module > as exemplified by the above example? > > Part 2: > > Consider the adaptation of the example program from Part 1: > > MODULE mod > INTEGER, PARAMETER :: jmin(1:10) = (/ (i, i = 1, 10) /) > CONTAINS > > SUBROUTINE one > i = 99 ! Is this a local or module variable? > ! Compilers that export I probably say module. > END SUBROUTINE > > SUBROUTINE two > PRINT *, i > END SUBROUTINE > > END MODULE > > The module specification part uses the variable I as an implied-DO variable > of an array constructor. Module procedure ONE sets a variable named I to > a value. > > Given: > > * An implicitly declared data object in the module specification part where > the variable has statement scope, and > > * An implicitly declared variable in a module procedure where the variable > has the same name as the variable described in the first bullet of this > list > > is the variable in the module procedure a module variable (known to the entire > module and thus available outside the module) or is the variable local to the > module procedure? > > > ANSWER: > > > EDITS: > > > SUBMITTED BY: Larry Rolison > HISTORY: J3/97-237 m143 submitted > > > Addendum: > A collection of email reactions to the question when the question was posted > to the J3 reflector: > > > Date: Tue, 20 May 1997 10:09:37 -0600 (MDT) > From: jeanne@niwot.scd.ucar.EDU (Jeanne Adams) > > Larry, the scope is the statement in this case, so I don't think it > is visible to a using program. > > - - - - - - - - - - > > Date: Tue, 20 May 1997 09:27:45 -0700 > From: Richard Maine > > I'd assume it was visible. Its type is certainly visible in the scope > of the module. (Try declaring a complex variable I in the module). > I can't see any rationale for why it wouldn't be visible with the USE. > > Or consider, for example, the case like > > MODULE TEST1 > INTEGER :: I > INTEGER, PARAMETER :: JMIN(1:10) = (/ (I,I=1,10) /) > END MODULE TEST1 > > Semantically no different - right? The INTEGER declaration just > makes the type of I explicit instead of implicit. I can't see > any way that the compiler can tell whether the INTEGER declaration > is just for the implied DO variable or whether it also implies > a variable of module scope. It seems to me that the rule has to be > that it also implies a variable of module scope. In other contexts > (namely not in a module), the compiler could notice that the > variable is never used and thus could be optimized away. In a module, > there is no way to tell that when compiling the module (as the > USEs are compiled later). > > Of course, if it were my own code, the module would have default > private accessibility, so only those things that I specifically > exported would be visible - but I understand that the compiler vendors > have to deal with all coding styles. > > This is one example of why I never have liked implied DO syntax - > things that should "logically" be completely internal to the implied > DO "escape" and have effects elsewhere. > > It is also an excellent example of the complications of the lack of > a clear "declare a variable" statement in Fortran. Instead of a > single statement that declares something to be a variable, you just > collect attributes and see in the end whether the set of attributes > looks like a variable. In this (and some other) case, its a bit > vague. We have the type integer associated with the name "I", but > we don't know explicitly whether I actually is meant to exist or not. > The only "safe" assumption is that it does. > > - - - - - - - - - - > > From: "Craig Dedo" > Date: Tue, 20 May 1997 12:28:51 -0400 > > My interpretation may not be legally correct, but here is how I see > it, based purely on my personal intuitive feel for what an ordinary > programmer would expect. > > Implied DO-loop variables in DATA DECLARATION statements are local > ONLY to the statements they are used in. > > Implied DO-loop variables in EXECUTABLE statements take the scope of > the variable that is used, i.e., module, local, global, COMMON, etc. > > This really is a hole in the standard. We should make this an erratum > and provide an edit to make rules clear. > > - - - - - - - - - - > > Date: Tue, 20 May 1997 09:35:42 -0700 > From: Richard Maine > > Craig Dedo writes: > > > Implied DO-loop variables in DATA DECLARATION statements are local > > ONLY to the statements they are used in. > > Then you'd expect this code to work? > > program oops > character*16 :: i = 'hello' > integer :: j(10) = (/ (i, i = 1 , 10) /) > write (*,*) i, j > end > > I think not. Looks to me like the implied DO-loop variable has at > least some effect outside of its scope. > > - - - - - - - - - - > > Date: Tue, 20 May 1997 09:39:34 -0700 > From: Bob Runyan > > Another data point: Our compiler gives a fatal error on the declaration > of I in the main program. > > - - - - - - - - - - > > From: vdecyk@pepper.physics.ucla.edu > Date: Tue, 20 May 1997 09:51:26 -0700 (PDT) > > The IBM xlf90 compiler does not complain and executes the code. > > The Fujitsu compiler frt issues the following error: > > Fortran 90 diagnostic messages: program name(MAINTEST) > jwd1763i-s "lrr.f", line 7: The attribute of the use associated name > cannot be redefined in this specification statement.(name:I) > > viktor decyk > > - - - - - - - - - - > > From: (Henry Zongaro) > Date: Tue, 20 May 1997 15:12:53 -0400 (EDT) > > Not surprisingly, I'd say the implied-DO variable should not be visible > to the using program. 14.1.3 Statement Entities states, in part, that > > The name of a variable that appears as the DO variable of an > implied-DO in a DATA statement or an array constructor has a scope > of the implied-DO list. It has the type and type parameter that it > would have if it were the name of a variable in the scoping unit > that includes the DATA statement or array constructor and this type > must be integer. > > I think the use of the words "would have if it were" were intended to convey > the idea that the existence of an array constructor or data implied-DO > variable doesn't actually cause an associated variable in the scoping unit > to come into existence. I believe that if the Cray and EPC implementations > are correct, the wording would have been more definite. > > Also, the following edit to Fortran 90 (same section) appeared as the > response to Interpretation 31: > > If the name of a global or local entity accessible in the scoping unit of > a statement is the same as the name of a statement entity in that > statement, the name is interpreted within the scope of the statement > entity as that of the statement entity. > > Again, I take the word "If" here to imply that there need not be any such > global or local entity with the same name as that of the statement entity. > > Thanks, > Henry > > - - - - - - - - - - > > Date: Tue, 20 May 1997 16:06:33 -0500 > From: Richard Bleikamp > > > What do you think? Is the implied-DO variable visible to the using program > > or not? > > No, its not. Henry's analysis is (in my opinion) correct. Shame on you for > not memorizing the entire F90 standard forwards, backwards, and sideways :). > > Fortunately Henry replied before I did, because I couldn't find the > statement entity paragraph, even though I thought it was there somewhere. > > rich > > - - - - - - - - - - > > Date: Wed, 21 May 1997 09:32:51 BST > From: Lawrie Schonfelder > > > What do you think? Is the implied-DO variable visible to the using program > > or not? > > My reaction is that this program SHOULD be standard conforming and that the I > in the implied-DO should have the scope of the implied-DO only and hence be > not an exportable entity of the module. I don't have a copy of the standard > handy so if this is not what the standard says then it should be changed so > that it does. To have such a usage result in the accidental creation of an > exportable visible module variable is a terrible thing to do to unsuspecting > users. > > - - - - - - - - - - > > Date: Wed, 21 May 1997 09:39:50 BST > From: Lawrie Schonfelder > > On Tue, 20 May 1997 09:35:42 -0700 Richard Maine wrote: > > > From: Richard Maine > > Date: Tue, 20 May 1997 09:35:42 -0700 > > > > Craig Dedo writes: > > > > > Implied DO-loop variables in DATA DECLARATION statements are local > > > ONLY to the statements they are used in. > > > > Then you'd expect this code to work? > > > > program oops > > character*16 :: i = 'hello' > > integer :: j(10) = (/ (i, i = 1 , 10) /) > > write (*,*) i, j > > end > > > > I think not. Looks to me like the implied DO-loop variable has at > > least some effect outside of its scope. > > In virtually every language other than Fortran there would be no question. > This would be a correct program and would have an obvious meaning. > > Inside the implied-DO scope, the I would be an integer and its existence would > mask the character I that exists in the outer scope. The I in the WRITE would > output "hello". Why must Fortran get so hung up about simple scope issues? > > - - - - - - - - - - > > From: "Dr. S. Morgan" > Date: Wed, 21 May 1997 10:20:31 +0100 (BST) > > Lawrie, > > The relevant section is 14.1.3 and it states > > "The name of a variable that appears as the DO variable of an implied-DO in > a DATA statement or an array constructor has a scope of the implied-DO list" > > So - I agree with your analysis, > > Cheers, > Steve. > > - - - - - - - - - - > > From: Jose Oglesby > Date: Thu, 22 May 1997 10:29:23 -0700 > > Here is a related potential problem I found in our compiler. I expect > that all the compilers that export "I" will have the same difficulty. > > -- jose > > MODULE TEST1 > INTEGER, PARAMETER :: JMIN(1:10) = (/ (I,I=1,10) /) > CONTAINS > SUBROUTINE BAR() > I = 99 ! Is this a local or module variable? > ! compilers that export I probably > ! say module. > END > SUBROUTINE BAZ() > PRINT *, I > END > END MODULE TEST1 > > - - - - - - - - - - > > Date: Tue, 16 Sep 1997 14:50:57 -0500 > > [ From a coworker of mine here at SGI/CRI ] > > > 1) There seems to be some confusion about the difference between scope > of the characteristics of I and the value of I. I think most would agree > that the value of I is restricted to the statement. It would certainly > be incorrect to assume that I had the value of 11 at run-time because of > this code. I believe the characteristic scope is a non-issue, since the > type must be integer and I can have no other characteristics. (section > 14.1.3). > > 2) I this case, there seems a clear distinction between run-time and > compile-time existence of I. The statement above is non-executable. The > characteristics of I are determined and used only during compilation. > There is no run-time code generated which involves I. Under these > circumstances, it is unreasonable that I would have an existence at > run-time. I assume this was the genesis of the rule about statement > scope in 14.1.3. I would propose that the text there be modified. > > Old text: > > "It is a scalar variable that has the type and type parameters that it > would have if it were the name of a variable in the scoping unit that > includes the DATA statement or array constructor, and this type shall be > integer; it has no other attributes." > > Proposed replacement text: > > "It is a scalar variable of type default integer, and is unrelated to > any other implicitly or explicitly declared variable of the same name in > the scoping unit that includes the DATA statement or array constructor." > > > I think that revision would make clear that the answer to the original > interp question is NO. An entity with statement scope is not visible > elsewhere in the scope of the program unit. > > > Larry Rolison lrr@cray.com > Cray Research, A Silicon Graphics Company > 655F Lone Oak Drive > Eagan, MN 55121 > ------------------------------------------------------------------------------- --------------------------------------------------------------------- Dr. J. S. Morgan Tel. 0151-794-3746 (3719 for messages) Computing Services Department Fax. 0151-794-3759 The University of Liverpool email. J.S.Morgan @ liverpool.ac.uk Chadwick Building Peach Street Liverpool L69 7ZF ---------------------------------------------------------------------