J3/00-253 Date: 24-June-2000 To: J3 Members From: interp/Stan Whitlock Subj: F95 interp letter ballot #2 - due 28-July-2000 Enclosed in the second letter ballot on Fortran 95 interpretations. The rules we operate on say: o J3 votes on the answer at a J3 meeting; a simple majority vote marks the answer as "passed by J3 meeting". o Between J3 meetings the chair of /interp sends a J3 letter ballot to J3 to approve interp answers that have been "passed by J3 meeting". The letter ballot runs for 30 days. Not voting on three of four consecutive J3 letter ballots is grounds to terminate J3 membership. An interp answer passes by a 2/3rds vote; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 6 Fortran 95 interpretations were passed at J3 meeting #153. In addition, interp 000029 passed at meeting #145. This is the letter ballot phase to go from "passed by J3 meeting" to "passed by J3 letter ballot". The following Fortran 95 interpretations are being balloted: Yes No Number Title --- --- 000001 Visibility of a data object with statement scope --- --- 000003 Ability to overload the character operator // --- --- 000004 Value returned by MAXVAL/MINVAL --- --- 000005 Value returned by SELECTED_REAL_KIND --- --- 000012 Evaluation of Intrinsic Procedures --- --- 000029 Association of a pointer actual argument with a dummy argument --- --- 000066 Errors in processing data transfer statements The text of these interpretetions is attached. Each interpretation starts with a row of "-"s. Please mark the above "yes" or "no" answer {be sure to include your reasons with "no"} and send only the above text {not this entire mail mail message} to x3j3@ncsa.uiuc.edu by Midnight, PDT, Friday, 28-Jul-2000, in order to be counted. Thanks /Stan ---------------------------------------------------------------------- NUMBER: 000001 TITLE: Visibility of a data object with statement scope KEYWORDS: visibility, data object, statement scope, scope DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting 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: 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. The first edit makes this clear. The second edit makes the same point for FORALL statements and constructs. EDITS: Page 280, Clause 14.1.3, at the end of the first paragragh (280:44) add: The appearance of a name as the DO variable of an implied-DO in a DATA statement or an array constructor is not an implicit declaration of a variable whose scope is the scoping unit that contains the statement. Page 281, Clause 14.1.3, at the end of the second paragraph [281:4] add: The appearance of a name as an index-name in a FORALL statement or FORALL construct is not an implicit declaration of a variable whose scope is the scoping unit that contains the statement or construct. SUBMITTED BY: Larry Rolison HISTORY: 97-237 m143 submitted 00-158 m153 passed unanimously ---------------------------------------------------------------------- NUMBER: 000003 TITLE: Ability to overload the character operator // KEYWORDS: overload, intrinsic, // DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting 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.) ANSWER: Intrinsic concatenation is defined only for character operands with the same kind type parameter value. This is stated clearly (90: 8-9): 'For the character intrinsic operator //, the kind type parameters shall be the same'. There is a need for a similar restriction at this point for relational intrinsic operators with character operands. The words at the end of the next paragraph (90: 12) actually suggest that there are relational intrinsic operations for character operands of different kind type parameter values that are not character relational intrinsic operations. The word 'requiring' in the last sentence in the note in Table 7.1 should be changed since all the intrinsic operators with character operands require their operands to have the same kind type parameter value. EDITS: Page 89, Table 7.1, penultimate line (89:38). Change 'requiring' to 'with'. Page 90, line 9. Add 'For the relational intrinsic operators with character operands, the kind type parameters shall be the same'. Page 90, line 12. Delete 'and have the same kind type parameter value'. SUBMITTED BY: Larry Rolison HISTORY: 97-239 m143 submitted 00-159 m153 passed unanimously ---------------------------------------------------------------------- NUMBER: 000004 TITLE: Value returned by MAXVAL/MINVAL KEYWORDS: MAXVAL, MINVAL DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting 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: 1. Yes. Processors may support values that are not present in the model of 13.7.1. IEEE -inf is an example of such a number and this may be returned on a machine that supports the IEEE standard. If the negative number of the largest magnitude in the model had been intended, the model would have been mentioned as, for example, in the definition of HUGE (13.14.39). 2. A simple example of its use is to test whether a set of numbers SET1 has a value greater than any value in the set SET2. Consider the expression MAXVAL (SET1) > MAXVAL (SET2). If SET1 is empty and SET2 is not, this value is correctly false even if all of the values are outside the model with values less than -HUGE (SET1). It may be helpful to consider how MAXVAL might be coded for an array of rank one on an IEEE computer. The following code is suitable. MAXVAL = IEEE_VALUE ( 1.0, IEEE_NEGATIVE_INF) DO I = 1, SIZE (ARRAY) MAXVAL = MAX (MAXVAL, ARRAY(I)) END DO All of the reduction functions (e.g., MAXVAL, SUM) return values when the arguments are zero-sized arrays that may be the same as the values returned for some non-zero-sized arguments. EDITS: None. SUBMITTED BY: Larry Rolison HISTORY: 97-240 m143 submitted 00-160r2 m153 Passed 7-5 ---------------------------------------------------------------------- NUMBER: 000005 TITLE: Value returned by SELECTED_REAL_KIND KEYWORDS: SELECTED_REAL_KIND DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting 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: The intention is that the value -1 be returned if the range can be supported but the precision cannot, the value -2 be returned if the precision can be supported but the range cannot, and the value -3 be returned if neither the precision nor the range can be supported. Provision needs to be made for the case where each can be supported, but not in combination. With the edit below, the returned values for the four invocations will be 16, -4, -1, -1. EDITS: Page 266, Clause 13.14.95, lines 11-14 (266: 26-29). Replace 'the result is -1 ... is supported.' by 'the result is -1 if the processor does not support a real data type with a precision greater than or equal to P but does support a real data type with an exponent range greater than or equal to R, -2 if the processor does not support a real data type with an exponent range greater than or equal to R but does support a real data type with a precision greater than or equal to P, -3 if the processor supports no real data type with either of these properties, and -4 if the processor supports real data types for each separately but not together.' SUBMITTED BY: Larry Rolison / Joanne Brixius HISTORY: 97-241 m143 submitted 00-161 m153 Passed unanimously as amended ---------------------------------------------------------------------- NUMBER: 000012 TITLE: Evaluation of Intrinsic Procedures KEYWORDS: Algorithm, Mathematical, Computational DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: 1. When the standard specifies an algorithm for computing a mathematical procedure, must a processor use the specified algorithm? Example: ANINT is defined as INT (A + 0.5). On some processors ANINT (16 000 001.0) evaluates to 16 000 002.0 using this algorithm. 2. May a processor return a mathematically equivalent result in the evaluation of a numeric intrinsic procedure? Example: If ANINT (16 000 001.0) can be computed as the more expected 16 000 001.0, may a processor do so? ANSWER: 1. No, a processor is not required to use the algorithm from the standard. 2. Yes, a processor may return the mathematically equivalent result in the evaluation of any numeric intrinsic procedure. DISCUSSION: The use of an algorithm in the definitions for intrinsic procedures is intended to describe the end result. It is not intended to require that a processor use a particular method of achieving that result. Thus, an algorithm specifies the mathematical results, not the computational results, of the evaluation of intrinsic procedures. This standard does not require a processor to use a particular accuracy or precision. Section 1.4, "Exclusions", states in part: "This standard does not specify: . . . (6) The physical properties of the representation of quantities and the method of rounding, approximating, or computing numeric values on a particular processor." [1:26, 1:37-38] EDITS: None. SUBMITTED BY: Keith H. Bierman HISTORY: 95-247r1 m134 Submitted as F90 interp 000202 with proposed response, approved 9-4, subsumes F90 interp 000200. 95-256 m134 Ballot failed, 10-6 95-260 m135 Proposed response, no action 96-023 m136 Proposed response, no action 96-054 m137 Proposed response, no action 96-117 m138 Proposed response, no action 97-259r1 m143 Re-submitted as F95 interp 000012 with proposed response 00-214 m153 Passed unanimously ---------------------------------------------------------------------- NUMBER: 000029 TITLE: Association of a pointer actual argument with a dummy argument KEYWORDS: derived type, assignment DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: According to Fortran 90, intrinsic assignment of derived type entities does not invoke defined assignment for components of these entities, even if it exists. Should this situation have been corrected in Fortran 95 to avoid breaking encapsulation of derived types? That is, in the example program below, is the final assignment statement intended to invoke the user-defined assignment routine for the "name" components of "a" and "b", or should it do pointer assignment on the (PRIVATE) "value" components of the "name" components? MODULE lib_varying_string TYPE varying_string PRIVATE CHARACTER,POINTER :: value(:) END TYPE INTERFACE ASSIGNMENT(=) MODULE PROCEDURE assign_vs_to_vs END INTERFACE CONTAINS SUBROUTINE assign_vs_to_vs(var,expr) TYPE(varying_string),INTENT(OUT) :: var TYPE(varying_string),INTENT(IN) :: expr ALLOCATE(var%value(SIZE(expr%value,1))) var%value = expr%value END SUBROUTINE END PROGRAM programme USE lib_varying_string TYPE mytype TYPE(varying_string) name END TYPE TYPE(varying_string) x,y TYPE(mytype) a,b x = y ! invokes "assign_vs_to_vs(x,(y))". a%name = b%name ! invokes "assign_vs_to_vs(a%name,(b%name))" a = b ! in F90, pointer assigns the "value" components END ANSWER: Yes, Fortran 95 should have corrected this mistake in Fortran 90. The final assignment above should invoke "assign_vs_to_vs(a%name, (b%name))". REFERENCES: ISO/IEC 1539:1997 (E) sections 7.5.1.2 and 7.5.1.5. EDITS: 1. Add a new item to the numbered list at the end of section 1.5.1 [3:32+] "(3) Intrinsic assignment for derived types now invokes defined assignment on nonpointer components for which the intrinsic assignment has been overridden by an interface block with an ASSIGNMENT(=) specifier." 2. Replace "and intrinsic assignment for nonpointer components." in section 7.5.1.5 [109:37] with ", defined assignment for nonpointer components of derived type for which there is an accessible interface block with an ASSIGNMENT(=) specifier for objects of that type, and intrinsic assignment for other nonpointer components." 3. In note 7.44, change "using the derived-type intrinsic assignment statement" [110:4-5] to "using defined assignment if there is an accessible interface block with an ASSIGNMENT(=) specifier overriding the intrinsic assignment for objects of that type, and using the derived-type intrinsic assignment statement otherwise." Note: This is MTE work item M16 for Fortran 2000. The corresponding edits to F2K have not been made as of 00-007r1. SUBMITTED BY: Malcolm Cohen HISTORY: 97-197 m142 Submitted 97-197 m145 Passed unanimously as amended {see 98-167 minutes} ---------------------------------------------------------------------- NUMBER: 000066 TITLE: Errors in processing data transfer statements KEYWORDS: ERR=; IOSTAT=; Data transfer statements DEFECT TYPE: Erratum STATUS: Passed by J3 meeting Consider the following program. INTEGER :: A(10), IDX, J OPEN(10, FORM='UNFORMATTED', ACCESS='SEQUENTIAL', STATUS='OLD', & ACTION='READ') READ(10, IOSTAT=IOS) IDX, J, A(IDX) END If an error occurs while processing the variable J in the data transfer statement, does this program become non-standard conforming? According to 9.4.3: "If an error condition or an end-of-file condition occurs during execution of an input/output statement, execution of the input/output statement terminates and if the input/output statement contains any implied-DOs, all of the implied-DO variables in the statement become undefined. If an error condition occurs during execution of an input/output statement, the position of the file becomes indeterminate. If an error or end-of-file condition occurs on input, all input list items become undefined." According to 9.4.4: "The effect of executing a data transfer input/output statement shall be as if the following operations were performed in the order specified: (1) Determine the direction of data transfer (2) Identify the unit (3) Establish the format if one is specified (4) Position the file prior to data transfer (9.2.1.3.2) (5) Transfer data between the file and the entities specified by the input/output list (if any) or namelist (6) Determine whether an error condition, an end-of-file condition, or an end-of-record condition has occurred (7) Position the file after data transfer (9.2.1.3.3) (8) Cause any variables specified in the IOSTAT= and SIZE= specifiers to become defined." A simple reading of this seems to indicate that the point at which the error occurs and is detected by a standard-conforming processor is unspecified. Because IDX becomes undefined, the reference to IDX in the variable A(IDX) is incorrect. However, this is a very common style of coding I/O operations in Fortran. QUESTION 1: Was it the committee's intent that such a program should not be standard-conforming in the presence of an error condition? QUESTION 2: Does the fact that the error occurred before the item A(IDX) was processed mean that there was no reference to IDX, and hence, that the program is standard-conforming? ANSWER 1: No. ANSWER 2: Yes. DISCUSSION: The referenced paragraph (9.4.4) is misleading. The entire I/O list is not necessarily expected to be processed in the presence of an error. EDIT: Section 9.4.4, list item 6 [150:33], delete "an error condition,", and change ", or" to "or" Section 9.4.4, add the following after list item (8): "If an error condition occurs during any of the above operations, execution of the data transfer statement terminates, any variable specified in an IOSTAT= specifier becomes defined, and the error condition is processed as described in 9.4.3." SUBMITTED BY: Henry Zongaro HISTORY: 99-177 m150 submitted 99-212 m150 approved uc 00-May failed J3 letter ballot 00-213 m153 passed unanimously