J3/00-204 Date: 25-May-2000 To: J3 From: Interp/Stan Whitlock Subj: text of interps 1,3,4,5 I notice that proposed answers to F95 interps 1,3,4,5 {papers 00-158, 159, 160, 161} do not have the original text of the interp attached. So those texts are below. /Stan ---------------------------------------------------------------------- NUMBER: 000001 TITLE: Visibility of a data object with statement scope KEYWORDS: visibility, data object, statement scope, scope DEFECT TYPE: Interpretation STATUS: J3 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 ------------------------------------------------------------------------------- NUMBER: 000003 TITLE: Ability to overload the character operator // KEYWORDS: overload, intrinsic, // DEFECT TYPE: Interpretation STATUS: J3 consideration in progress QUESTION: On page 89 of the Fortran 95 standard, the Note at the bottom of Table 7.1 states in part: For the intrinsic operators REQUIRING {emphasis not in standard} operands of type character, the kind type parameters of the operands shall be the same. Since there is only one intrinsic operator (//) that REQUIRES its operands to be of type character, one may conclude that the operands of the // operator MUST be of type character and MUST have the same kind type parameters. The last sentence of the first full paragraph on page 90 restates the above rule for intrinsic uses of // as follows: For the character intrinsic operator //, the kind type parameters shall be the same. Contrast this with the last sentence of the last paragraph of this section: A {character relational intrinsic operation} is a relational intrinsic operation where the operands are of type character and have the same kind type parameter value. From the wording of this last sentence, one may conclude that if the kind type parameters are the same, then the relational operation is intrinsic but if the kind type parameters are NOT the same, then the relational operation is NOT intrinsic and must be defined via a user-provided function. Thus, it is possible for the character operands of a relational operator to have differing kind type parameter values. Now compare this to the following sentence from 7.1.4.2: For an expression // where and are of type character, the character length parameter is the sum of the lengths of the operands and the kind type parameter is the kind type parameter of , which shall be the same as the kind type parameter of . Note that there is no text or title to indicate that the description is only for intrinsic operators. There appears to be no way to overload the // symbol at all since the wording does not restrict the rule to the intrinsic interpretation of the operator (it appears in fact from the wording that once the operands are of type character, there can be no other interpretation other than intrinsic). This is surely not what was intended. The wording should be redone to more closely resemble that for the character relational operators such that if the operands of // do not have the same kind type parameters, an overload is allowed (and the operator is not interpreted as being intrinsic). (See also 7.2.2 Character intrinsic operation.) Suggested edits: 1. Delete the last sentence of the first full paragraph on page 90. 2. Add the following sentence to the last paragraph of 7.1.2: A {character concatenation intrinsic operation} is a concatenation operation where the operands are of type character and have the same kind type parameter value. 3. In the second sentence of the third paragraph of 7.1.4.2, insert "and have the same kind type parameter value" ahead of the first comma. ANSWER: EDITS: SUBMITTED BY: Larry Rolison HISTORY: J3/97-239 m143 submitted Addendum: An email response from Richard Maine when I pointed the inconsistency out to him: Date: Tue, 8 Jul 1997 09:00:25 -0700 To: Larry Rolison Subject: Re: Another f2k edit I [also] noticed the difference in terminology ... My reading is that the difference is just sloppily inconsistent wording (which should be fixed for f2k) rather than a real difference between concat and the char relationals. I suspect that it is just the *intrinsic* concat that "requires" kind agreement - if it doesn't hold, then you don't have the intrinsic concat, but could still overload one. In other words, even though the wording is different, I think they are trying to say the same thing. I certainly can't think of any reason why they *should* be different. But I haven't really researched it - nor do I have time to right now. ------------------------------------------------------------------------------- NUMBER: 000004 TITLE: Value returned by MAXVAL/MINVAL KEYWORDS: MAXVAL, MINVAL DEFECT TYPE: Interpretation STATUS: J3 consideration in progress QUESTION: The Result Value section of the MAXVAL intrinsic function description uses the phrasing: or has the value of the negative number of the largest magnitude supported by the processor for numbers of the type and kind type parameter of ARRAY if ARRAY has size zero This phrasing has generated at least the two following views on the return value: * If the machine supports the IEEE standard then the implementation should return -inf. * For portability, the implementation should return -HUGE(ARRAY). These views lead to the following questions: 1. Is the intent of the standard to describe the result in terms of machine values rather than model values? 2. If the answer to 1 is "yes", how are programmers expected to use this intrinsic function portably? ANSWER: EDITS: SUBMITTED BY: Larry Rolison HISTORY: J3/97-240 m143 submitted - - - - - - - Date: Thu, 18 Sep 1997 13:38:50 -0500 [ From a coworker here at SGI/CRI ] The first question boils down to: on an IEEE-like hardware platform which has a bit pattern for -infinity, does this qualify as "a value ... supported by the processor"? The result of MAXVAL must be of the same type and kind as the argument. Since -infinity would only be possible if the arguments were of type real, one would have to conclude that -infinity was a valid real value. If that is true, then there would be at least one argument for which some intrinsics (EXPONENT, FRACTION) would fail. Based on this I would argue that returning -infinity should be invalid. I also think it is unwise, based on the discussion below. I think that the real problem is that there is no clean way to return a "failed" status from MAXVAL. Both the -huge() and the -infinity methods are defective attempts at solving that problem. It is not clear that the choice of -infinity is in any way superior to -HUGE(). If a machine allows -infinity, and all the tested elements in the array were -infinity, then you would expect that -infinity would be returned. But then is it the "answer" or is it an "error"? There is no way to tell. Returning -HUGE() suffers from exactly the same defect. I believe that there are a couple of drawbacks to the use of -infinity. 1) You might like to write code of the following form: answer = maxval(array, mask=larray) if (answer == xxxxx) then ! code for the case that all the elements in larray are .false. else ! code the the cae that answer is a meaningful result end if What do you use for xxxxx? In the current model, -HUGE(array) should be a workable and portable form. If the alternate -infinity version were used, then there would have to be a way in Fortran to represent -infinity. It's not clear that is always possible, and most likely not in a portable fashion. 2) The MAXVAL function allows either real or integer arguments. On an IEEE machine (for example) -infinity only has meaning for reals; the concept of -infinity makes no sense for integer arguments. It seems an unnecessary complication to have one scheme for reals and a different one for integers. ------------------------------------------------------------------------------- NUMBER: 000005 TITLE: Value returned by SELECTED_REAL_KIND KEYWORDS: SELECTED_REAL_KIND DEFECT TYPE: Interpretation STATUS: J3 consideration in progress QUESTION: The SELECTED_REAL_KIND intrinsic function does not appear to cover one specific case for real data types. Consider the following precisions and ranges for a particular model: KIND TYPE PRECISION RANGE 4 6 37 8 15 307 16 31 291 A test case for a system with this model is: PRINT *, 'selrealkind(31,291) = ', SELECTED_REAL_KIND(P=31,R=291) PRINT *, 'selrealkind(31,292) = ', SELECTED_REAL_KIND(P=31,R=292) PRINT *, 'selrealkind(32,291) = ', SELECTED_REAL_KIND(P=32,R=291) PRINT *, 'selrealkind(32,292) = ', SELECTED_REAL_KIND(P=32,R=292) END The Result Value section of the description of SELECTED_REAL_KIND clearly describes the result value when the values of P and R are within the ranges specified for the given implementation of the real data type model. It further describes the values to be returned by SELECTED_REAL_KIND when a value of P or R is not within the range of model numbers specified by the implementation. From the text in the Result Value section, the following may be determined: * The reference to SELECTED_REAL_KIND(P=31,R=291) (first PRINT line) should return the (kind type parameter) value 16. * The third and fourth SELECTED_REAL_KIND references should return -1 since the PRECISION argument is outside the set of allowed precision values. However, the value returned by the second reference to SELECTED_REAL_KIND is unknown since it does not appear to be covered by the wording of the Result Value paragraph of section 13.14.95. 1. What should the processor return for the value of the SELECTED_REAL_KIND intrinsic function when it does not have a single data type that satisfies both the P and R values? 2. In particular, given the precision and range values shown above, what should the processor return for the last three invocations of the SELECTED_REAL_KIND intrinsic function? ANSWER: EDITS: SUBMITTED BY: Larry Rolison / Joanne Brixius HISTORY: J3/97-241 m143 submitted