J3/01-274 Date: 26-Jun-2001 To: J3 Members From: interp/Stan Whitlock Subj: F95 interp letter ballot #5 - due 20-Jul-2001 Enclosed in the fifth letter ballot on Fortran 95 interpretations. The rules we operate by 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. 7 Fortran 95 interpretations were passed at J3 meeting #157. 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 --- --- 000031 Association of pointer function result with INTENT(OUT) dummy argument --- --- 000094 NULL intrinsic in initialization expressions --- --- F90/000190 Subobjects of constants in a DATA statement --- --- F90/000191 Interaction of SEQUENCE derived types and rename --- --- F90/000196 Inaccessibility of intrinsic procedures --- --- F90/000204 Meaning of "same variable" description of MVBITS --- --- F90/000205 Restrictions on EXTERNAL The text of these interpretetions is attached. Each interpretation starts with a row of "-"s. Please mark the above -Y- in the Yes column for "yes", -C- in the Yes column for "yes with comment", or -N- in the No column for a "no" answer {be sure to include your reasons with "no"} and send only the above text {not this entire mail mail message} to j3@j3-fortran.org by Midnight, PDT, Friday, 20-Jul-2001, in order to be counted. WG5 meets in London 30-Jul-3-Aug-2001. The sooner I know any of these interps will pass the J3 letter ballot, the sooner I can get the final interp answer to John Reid for possible WG5 ballot so please vote as early as possible. Thanks /Stan ---------------------------------------------------------------------- NUMBER: 000031 TITLE: Association of pointer function result with INTENT(OUT) dummy argument KEYWORDS: Pointer association, dummy argument association, intent attribute DEFECT TYPE: Erratum STATUS: Passed J3 meeting QUESTION: Consider the following program. PROGRAM P INTEGER, TARGET :: T CALL SUB(FPTR()) CONTAINS FUNCTION FPTR() INTEGER, POINTER :: FPTR FPTR => T END FUNCTION FPTR SUBROUTINE SUB(IO) INTEGER, INTENT(OUT) :: IO IO = 17 END SUBROUTINE SUB END PROGRAM P According to 12.4.1 [200:30-32], "If a dummy argument is not a pointer and the corresponding actual argument is a pointer, the actual argument shall be currently associated with a target and the dummy argument becomes argument associated with that target." According to 12.4.1 [201:19-21], "If a dummy argument has INTENT(OUT) or INTENT(INOUT), the actual argument shall be definable." According to 5.1.2.3 [53:29-31], "The INTENT(OUT) attribute specifies that. . . any actual argument that becomes associated with such a dummy argument shall be definable." The definition of "definable" supplied in Annex A (the term does not appear to be defined in normative text) is: "A variable is <> if its value may be changed by the appearance of its or on the left of an ." According to this definition, "definable" is a property of variables only. In the example above, the actual argument is not a variable. However, the actual argument is pointer associated with an object that is definable. The text cited from 5.1.2.3 refers to the "actual argument that becomes associated with the dummy argument", but the first piece of text cited from 12.4.1 makes it clear that when the actual argument is a pointer, it is the target with which it is associated that becomes argument associated with the dummy argument, and not the actual argument itself. Was it the intent of the committee that this program should not be standard-conforming? ANSWER: The program does not conform to the Standard. 12.4.1.1 [201:19-21] requires the actual argument to be definable and a function result is not definable. For example, it is not permitted on the left-hand side of an assignment statement, since it is not a variable. The edits add additional text to make this clear. EDITS: In subclause 5.1.2.3, on line 3 of the paragraph that starts 'The INTENT(OUT)' [53:31], add 'a variable that is' before 'definable'. In subclause 5.1.2.3, on line 3 of the paragraph that starts 'The INTENT(INOUT)' [53:36], add 'a variable that is' before 'definable'. In subclause 5.1.2.3, add at the end of the last paragraph [53:38] 'The dummy argument is not definable unless the actual argument is a variable that is definable.'. In subclause 12.4.1.1, on line 20 of page 201 [201:20], add 'a variable that is' before 'definable'. SUBMITTED BY: Henry Zongaro HISTORY: 98-177 m146 Submitted WG5/N1414 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot 01-200 m157 Passed by J3 meeting 10-2 ---------------------------------------------------------------------- NUMBER: 000094 TITLE: NULL intrinsic in initialization expressions KEYWORDS: NULL intrinsic, initialization expressions DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Section 7.1.6.1 says that an initialization expression may contain "(6) A reference to the transformational intrinsic function NULL," with no constraints on its argument. Therefore PROGRAM EXAMPLE CALL SUB(42) CONTAINS SUBROUTINE SUB(N) CHARACTER(N),POINTER :: CP INTEGER,PARAMETER :: M = LEN(NULL(CP)) REAL,SAVE :: X(M) END SUBROUTINE END is apparently standard-conforming, but it is difficult to see how this can work in practice, particularly if SUB were called with different values for N. Should there not be some constraint on the argument of NULL in an initialization expression? ANSWER: Yes, a constraint is needed to force initialization expressions always to be constant. An edit is supplied to correct this oversight. EDITS: [94:12+] add to end of list item "where the argument is not of type character with a length that is assumed or defined by an expression that is not an initialization expression." SUBMITTED BY: Malcolm Cohen HISTORY: 01-211 m157 Submitted 01-211r1 m157 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F90/000190 TITLE: Subobjects of constants in a DATA statement KEYWORDS: DATA stmt, constant DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: Consider the following syntax rules from Section 5.2.9 of the Fortran 90 standard: R532 is [*] R533 is ... R534 is and the following constraint Constraint: A of a must involve as primaries only constants or DO variables of the containing s, and each operation must be intrinsic. In all cases, the rules reduce to "constant". The definition of "constant" is provided by R305: R305 is or R307 is The above two rules seem to indicate that if an identifier appears where "constant" is allowed in the DATA statement rules cited above, the identifier must be a name; that is, it can not be the subobject of a named constant. Is this analysis correct? ANSWER: Your analysis is correct for the Fortran 90 standard, but it is not correct for the Fortran 95 standard, which permits subobjects of named constants in these situations. The corresponding rules (page 62) are Constraint: A of a shall involve as primaries only constants, subobjects of constants, or DO variables of the containing s, and each operation shall be intrinsic. R539 is or R540 is or ... EDITS: None SUBMITTED BY: Larry Rolison HISTORY: 94-302 m131 submitted, with proposed response 94-360 m131 alternate answer proposed, failed 7-7 94-302 m131 original answer, approved 14-2 95-034 m132 X3J3 ballot failed 15-5 01-201 m157 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F90/000191 TITLE: Interaction of SEQUENCE derived types and rename KEYWORDS: SEQUENCE, derived type, use association DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: Consider the following: MODULE M TYPE T SEQUENCE TYPE (T), POINTER :: P END TYPE END MODULE USE M, T2=>T TYPE T SEQUENCE TYPE (T2), POINTER :: P END TYPE TYPE (T) X TYPE (T2) Y X = Y END Section 4.4.2, 'Determination of derived types', seems to indicate that types T and T2 in the main program refer to the same type. Note that both types have structure components that agree in order, name, and attributes. However, considering type T in the context of module M only, type T is a derived type that contains one component that is a pointer to itself. In the context of the main program, type T is a derived type that contains one component that is a pointer to a different derived type. Are types T and T2 considered to be the same type? ANSWER: Yes, T and T2 are the same type. DISCUSSION: By the use of rename, it is possible for a scoping unit to have access by different local names to two separate derived-type definitions that have the same original name. Section 4.4.2 says: 'Data entities in different scoping units also have the same type if they are declared with reference to different derived-type definitions that have the same name,... '. This wording makes clear that it is the name of the derived-type definition (the original name) that is crucial when deciding whether two types are the same, rather than the local name of the type. This is confirmed in NOTE 4.32. EDITS: None. SUBMITTED BY: Janice C. Shepherd HISTORY: 94-273 m130 submitted 94-377 m131 Response submitted, approved u.c. 95-034r1 m132 X3J3 ballot failed 15-5 01-219 m157 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F90/000196 TITLE: Inaccessibility of intrinsic procedures KEYWORDS: intrinsic procedure, INTRINSIC attribute, generic identifier, names class DEFECT TYPE: Clarification STATUS: Passed by J3 meeting QUESTION: Note 14.2 states: "An intrinsic procedure is inaccessible in a scoping unit containing another local entity of the same class and having the same name. For example, in the program fragment SUBROUTINE SUB ... A = SIN (K) ... CONTAINS FUNCTION SIN(X) ... END FUNCTION SIN END SUBROUTINE SUB any reference to function SIN in subroutine SUB refers to the internal function SIN, not to the intrinsic function of the same name." Are the following two comments about this text correct? (1) The example is not strictly correct because the resolution of the procedure reference "SIN" depends on the contents of the first "...": (1a) If "..." does not contain an "INTRINSIC SIN" statement, the behavior is as specified: In SUB, the name SIN is established specific due to condition 14.1.2.4 part (2b), it is not established generic, and the internal function SIN is referenced due to 14.1.2.4.2 part (3). (1b) If "..." does contain an "INTRINSIC SIN" statement, SIN is established specific as above, but also established generic due to condition 14.1.2.4 (1b). So the reference is resolved according to 14.1.2.4.1 part (2): the intrinsic function SIN is called. ( At least if there is a suitable specific function for data ) ( object K. If not, the reference is resolved according to ) ( 14.1.2.4.1 (4) which also requires a consistent reference. ) (2) The first sentence of the cited text is wrong (incomplete), because it does not consider the case of generic identifiers: * Intrinsic procedures are local entities of class (1). * Generic identifiers are local entities of class (1). * Various instances in the standard indicate that it is possible to extend the generic interface of intrinsic procedures. Consequently, in the example MODULE my_sin CONTAINS LOGICAL FUNCTION lsin (x) LOGICAL, INTENT(IN) :: x ... END FUNCTION lsin END MODULE my_sin SUBROUTINE sub USE my_sin INTERFACE SIN MODULE PROCEDURE lsin END INTERFACE SIN ... END SUBROUTINE sub the intrinsic procedure SIN remains accessible in SUB although that scoping unit contains another local entity of class (1) named SIN. ANSWER: Comment 1a is correct. Comment 1b is incorrect. SIN is a local name for the internal procedure, which is a specific procedure, and adding an "INTRINSIC SIN" statement is prohibited by 14.1.2, 3rd paragraph. Comment 2 is correct. It should be remembered that notes are not normative (see 1.6.1) and are written in a less formal way than the text of the standard. DISCUSSION: Ordinarily, uses of intrinsic procedures are recognized automatically and require no explicit declaration, even if IMPLICIT NONE is in effect. However, if a scoping unit contains another local entity of the same class and having the same name as an intrinsic procedure, the automatic recognition of the intrinsic procedure is prevented, except in the case that the local entity and intrinsic procedure are both generic procedures. SUBMITTED BY: Michael Hennecke HISTORY: 95-252 m135 submitted 95-281 m135 response WG5 approved (N1161) 96- m136 X3J3 ballot failed 16-0, possible error in 2nd edit, WG5 approval removed. Barber edit applied 01-221r1 m157 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F90/000204 TITLE: Meaning of "same variable" description of MVBITS KEYWORDS: MVBITS DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Section 13.14.75 states "TO ... may be the same variable as FROM". Given the following statements, which pairs of variables are the same? INTEGER :: I(10), J(10) EQUIVALENCE (I,J) INTEGER, TARGET :: T(2:11) INTEGER, POINTER :: P1(:), P2(:) P1 => T P2 => T(2:11) I and I P1 and T I(1) and I(1) P1 and T(2:11) I(1:10) and I(1:10) P2 and T I(1:1) and I(1:1:-1) P2 and T(2:11) I and I(1:10) P1 and P2 I and J I(1) and J(1) I(1:10) and J(1:10) I(1:1) and J(1:1:-1) I and J(1:10) ANSWER: The quoted wording makes it clear that calls with the same name for FROM and TO, such as CALL MVBITS(DATA,2,2,DATA,0) ! Overwrite bits 0,1 by bits 2,3 are permitted. It was also intended that associated variables be permitted. The edits correct this. EDITS: In the second line of the final paragraph of subclause 12.7.3 [215:4], after 'may be the same variables', add 'and may be associated scalar variables or associated array variables all of whose corresponding elements are associated'. In subclause 13.14.75, in the second line of the paragraph that defines the effect of TO [258:21] change 'and may be the same variable as FROM' to 'and may be associated with FROM (12.7.3)'. SUBMITTED BY: /jor in response to IBM public comments HISTORY: 95-299 m135 submitted 01-220r1 m157 Passed by J3 meeting ---------------------------------------------------------------------- NUMBER: F90/000205 TITLE: Restrictions on EXTERNAL KEYWORDS: EXTERNAL attribute, external subprogram DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Let the following two procedures not be contained within a main program, a module, or another subprogram. In this case they are <>s by the definitions of Fortran 95, section 2.2: SUBROUTINE subroutine_subprogram ( ) ! ... END SUBROUTINE subroutine_subprogram FUNCTION function_subprogram ( ) INTEGER :: function_subprogram ! ... END FUNCTION function_subprogram They are also external procedures, since F95 section 2.2.3.1 (and 12.1.2.2) states that "An <> is a procedure that is defined by an external subprogram or by means other than Fortran." External functions may be given the EXTERNAL attribute in form of an (R503), external procedures may be given the EXTERNAL attribute by an (R1208). QUESTION 1: Is it correct that the current definitions in F95 do allow the EXTERNAL attribute to be specified for the name of the external subprogram in which such a declaration is contained? In other words, is the following code standard-conforming? SUBROUTINE subroutine_subprogram ( ) EXTERNAL subroutine_subprogram ! ... END SUBROUTINE subroutine_subprogram FUNCTION function_subprogram ( ) INTEGER, EXTERNAL :: function_subprogram ! ... END FUNCTION function_subprogram QUESTION 2: If the answer to question 1 is YES: was this the intention, or should it be prohibited that an EXTERNAL attribute is given to the name of an external subprogram by declarations within that subprogram? ANSWER: 1. No, the EXTERNAL attribute may not be specified for the name of an external procedure defined by the subprogram, but this is not said explicitly. An edit is supplied to correct this. 2. Not applicable. DISCUSSION: The final paragraph of subclause 12.3.2.2 states [197:30-32] 'A name that appears in an EXTERNAL statement in a given scoping unit ... shall not also appear as a specific procedure name in an interface block in the scoping unit nor in an interface block that is accessible to the scoping unit.' The intention was to disallow the EXTERNAL attribute for a procedure with an explicit interface. Subclause 12.3.1 states [193:1-2]; 'The interface of a recursive subroutine or a recursive function with a separate result name is explicit within the subprogram that defines it.'. It was intended that the EXTERNAL attribute should not be permitted for these cases since the interface is explicit. Only in the cases mentioned in the previous paragraph may an external procedure name be used as a procedure name in the interior of the subprogram that defines it. In other cases, there would be no value in specifying the EXTERNAL attribute. EDITS: In subclause 12.3.2.2, add at the end of the first paragraph after R1208 [197:17] 'In an external subprogram, an EXTERNAL statement shall not specify the name of a procedure defined by the subprogram'. SUBMITTED BY: Michael Hennecke HISTORY: 96- m136 submitted WG5/N1404 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot 01-202 m157 Passed by J3 meeting