From owner-sc22wg5 Fri Oct 26 17:48:41 2001 Received: from nameserv.rl.ac.uk (nameserv.rl.ac.uk [130.246.135.129]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id RAA93758 for ; Fri, 26 Oct 2001 17:48:40 +0200 (CEST) (envelope-from jkr@jkr.cc.rl.ac.uk) Received: from jkr.cc.rl.ac.uk (jkr.cc.rl.ac.uk [130.246.8.20]) by nameserv.rl.ac.uk (8.8.8/8.8.8) with ESMTP id QAA18437 for ; Fri, 26 Oct 2001 16:48:39 +0100 Received: (from jkr@localhost) by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id QAA17624 for SC22WG5@dkuug.dk; Fri, 26 Oct 2001 16:50:55 +0100 (BST) Date: Fri, 26 Oct 2001 16:50:55 +0100 (BST) From: John Reid Message-Id: <200110261550.QAA17624@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: WG5 letter ballot on Fortran 95 interpretations MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Dear WG5 members, This is the final set of draft interpretations for Corrigendum 2. They have just passed a J3 letter ballot. I have made minor corections to items 71 and 86, as requested with YES ballots by J3 members. A copy of this document is on the server as N1468. Since time is short, there will be a simultaneous letter ballot on Corrigendum 2 itself. The rules we operate on say: 4. The chair of J3/interp gathers all interp answers that are marked "passed by J3 letter ballot" and forwards them to the WG5 convenor. The WG5 convenor holds a ballot of individual members; a no vote must be accompanied by an explanation of the changes necessary to change the member's vote to yes. The answers that pass this ballot become "WG5 approved". J3/interp reserves the right to recall an interp answer for more study even if the answer passes. 5. "WG5 approved" answers are processed into a corrigendum document by taking the edits from the interp answers and putting them in the format required by ISO. A WG5 vote is made on forwarding the corrigendum to SC22. The following Fortran 95 interpretations are being balloted: Yes No Number Title --- --- 000007 Optional intrinsic function arguments --- --- 000009 INTENT of MOLD argument to TRANSFER --- --- 000026 List-directed input: types of variables corresponding to repeated values --- --- 000027 Sequential formatted I/O: position of the left tab --- --- 000066 Errors in processing data transfer statements --- --- 000067 Writing zeros --- --- 000071 Character array constructors --- --- 000086 Definition status requirements for defined operations --- --- 000091 Definition of "present" is defective --- --- 000095 Names of functions, results and entry points --- --- 000097 Open Scratch File Example --- --- F90/000164 Use of ONLY with multipart definitions --- --- F90/000209 STOP|PAUSE in I/O statement --- --- F90/000211 Multiple MODULE PROCEDURE specs --- --- F90/000212 EQUIVALENCE of Data Objects of Different Types or Kinds --- --- JP-04 Construction of derived-type values --- --- JP-05 Construction of array values --- --- JP-08 Type declaration statements --- --- JP-16 Multiple occurrence of namelist-group-name in NAMELIST statement --- --- JP-17 Multiple occurrence of namelist group object in namelist group --- --- JP-31 Signs of literal constants 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 sc22wg5@dkuug.dk by midnight Friday, 23 November 2001, in order to be counted. Thanks, John. ---------------------------------------------------------------------- NUMBER: 000007 TITLE: Optional intrinsic function arguments KEYWORDS: intrinsic function, argument - optional DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting BACKGROUND: Interpretation request 000053 asked the following question: QUESTION: Should constraining text be added to the description of optional argument Y in CMPLX, and optional argument BACK in INDEX, and optional argument SIZE in ISHFTC, and optional argument A3,... in MAX, and optional argument A3,... in MIN, and optional argument BACK in SCAN, and optional argument BACK in VERIFY to state that the argument must not be an optional argument of an invoking procedure? and it was answered as follows: ANSWER: In principle yes; however it is more appropriate to add an additional restriction on dummy arguments not present in section 12.5.2.8. Discussion: The standard contains numerous restrictions intended to ensure that the rank of a given expression never changes. The case of elemental functions with optional arguments was inadvertently overlooked. Consider the following subprogram: SUBROUTINE SUB (A,B,C) INTEGER :: A ,B INTEGER, OPTIONAL :: C (:) PRINT *, MAX (A, B, C) END When C is present, the result of the elemental function MAX, is an array of the same shape as C. However, if SUB were to be called with the third argument omitted, the result would be a scalar. The supplied edit remedies this deficiency. Corrigendum 1 then edited the Fortran 90 standard as follows: EDITS: 1. Add the following point to the numbered list in section 12.5.2.8: [179:38] (5) If it is an array, it must not be supplied as an actual argument to an elemental procedure unless an array of the same rank is supplied as an actual argument corresponding to a nonoptional dummy argument of that elemental procedure. 2. In the paragraph following the numbered list, replace "It" with "Except as noted in (5) above, it" [179:39] Corrigendum 3 modified the above edit as follows as part of the response to Interpretation request 000193: EDITS: 1. In Section 12.5.2.8, add the following to the numbered list after the list item added by Corrigendum 1 [179:38+]: "(6) If it is a pointer, it must not be supplied as an actual argument corresponding to a nonpointer dummy argument other than as the argument of the PRESENT intrinsic function." 2. In Section 12.5.2.8, in the text added by Corrigendum 1 to the last sentence of the section [179:39]: change "in (5)" to "in the list" The text as modified appears at the end of 12.4.1.5 on page 203 of the Fortran 95 standard. QUESTION: While the response to interpretation request 000053 stated "in principle" that an optional dummy argument should not be passed to an optional argument of a called procedure, and it closed a "loophole" for optional array dummy arguments, it still did not address the simpler case of an optional scalar dummy argument being passed to the cited intrinsics. Consider the following example: SUBROUTINE sub(string, substring, direction) CHARACTER(*) :: string, substring LOGICAL, OPTIONAL :: direction k = INDEX(string, substring, direction) ... END SUBROUTINE The last paragraph of 12.4.1.5 states: Except as noted in the list above, it may be supplied as an actual argument corresponding to an optional dummy argument, which is then also considered not to be associated with an actual argument. The only case in "the list above" that is relevant is (1) because DIRECTION is a dummy data object and is not an array or pointer. But (1) does not apply because the appearance of DIRECTION as an actual argument is not a reference by the following from 2.5.5: The appearance of a data object name, data subobject designator, or procedure name in an actual argument list does not constitute a reference to that data object, data subobject, or procedure unless such a reference is necessary to complete the specification of the actual argument. The appearance of DIRECTION is not "necessary to complete the specification of" DIRECTION, so therefore it is not a reference so therefore (1) does not apply. Thus, the last paragraph of 12.4.1.5 does seem to apply which indicates that an optional dummy argument can be passed to an optional argument of an intrinsic procedure such as INDEX. However, this does not seem to agree with the "principle" espoused in the answer to interpretation request 000053, nor does the description of INDEX seem to indicate how the result is to be determined if the BACK argument is specified but is not present. (One could possibly construe the phrase "If BACK is absent" to mean "specified but not present" but that does not seem to be the intent of the existing wording or the "principle" espoused in interpretation request 000053.) For an intrinsic procedure that has an optional argument, may an optional dummy argument be passed to the optional argument of the intrinsic procedure? ANSWER: Yes. DISCUSSION: It is clear from the wording of the standard, as cited in the question, that this is allowed. Furthermore, it is clear from the wording in the CMPLX intrinsic that this was not unintentional. EDITS: None. SUBMITTED BY: Larry Rolison HISTORY: J3/97-243 m143 submitted WG5/N1452 Suggested revision 01-287 m158 Passed by J3 meeting 01-xxx m158 Passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: 000009 TITLE: INTENT of MOLD argument to TRANSFER KEYWORDS: intrinsic function, TRANSFER, MOLD DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: In 13.3 [page 218:2], Fortran 95 states: The nonpointer dummy arguments of the generic intrinsic procedures in 13.14 have INTENT(IN) if the intent is not stated explicitly. In general, an actual argument that corresponds to a dummy argument that does not have the INTENT(IN) attribute does not need to be defined; you need to look at the particulars of the invoked procedure to decide if an actual argument needs to be defined before the invocation. It is likely that the only intrinsic procedure argument affected by this change in wording is the MOLD argument to the TRANSFER function. The value of the MOLD argument is never needed so there is no reason to define it before invoking TRANSFER in a Fortran 90 program. But, apparently it needs to be defined in a Fortran 95 program. This could break a program that uses a local name in a subroutine as the MOLD argument and doesn't always define the name with a value, or didn't save it. In this case, MOLD is like the arguments to the numeric inquiry functions, the "attribute" is a compile time characteristic, not a run-time "value" and should have the same exception as for the inquiry functions. (1) Was general statement about INTENT(IN) quoted above intentionally added to the Fortran 95 standard (how did it get into the standard)? (2) Is it the intent of the standard to apply this general statement to the MOLD argument of the TRANSFER intrinsic function? ANSWER: (1) Yes. (2) Yes, but this should not imply that the MOLD argument needs to be defined. An edit is supplied to clarify this situation. EDITS: [219:28+] Add new sentence to end of paragraph: "If the MOLD argument to this function is a variable, it need not be defined." SUBMITTEDBY: Larry Rolison / Dick Hendrickson HISTORY: J3/97-246 m143 submitted WG5/N1452 Suggested revision 01-288 m158 Passed by J3 meeting 01-xxx m158 Passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: 000026 TITLE: List-directed input: types of variables corresponding to repeated values KEYWORDS: list-directed, repeat DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: Consider the example CHARACTER*80 STRING COMPLEX Z READ (*, *) Z, STRING Suppose the input consists of 2*(1.0, 0.0) After the READ, should Z contain (1.0,0.0) and should STRING contain '(1.0,'? ANSWER: No. This is not standard conforming. See the answer to interpretation number 000025. SUBMITTED BY: Robert Corbett HISTORY: 98-155 m145 Submitted (part 4) WG5-N1456 Draft answer 01-306r1 m158 Passed by J3 meeting 01-xxx m158 Passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: 000027 TITLE: Sequential formatted I/O: position of the left tab KEYWORDS: format, tab DEFECT TYPE: Clarification STATUS: Passed by J3 meeting QUESTION: When a file is positioned within a record at the start of sequential formatted I/O, where is the left tab limit (see Section 10.6.1.1)? Is it at the start of the record or at the point where the file was positioned at the start of execution of the statement? ANSWER: The left tab limit is the point where the file was positioned at the start of execution of the statement. DISCUSSION: This follows from the second sentence of 10.6.1.1, which states "Immediately prior to data transfer, the left tab limit becomes defined as the character position of the current record." EDITS: None. SUBMITTED BY: Robert Corbett HISTORY: 98-155 m145 Submitted (part 5) WG5/N1452 Suggested answer 01-289 m158 Passed by J3 meeting 01-xxx m158 Passed by J3 letter ballot ---------------------------------------------------------------------- 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. EDITS: 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 00-254 m154 Failed J3 letter ballot 01-295r1 m158 Passed by J3 meeting 01-xxx m158 Passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: 000067 TITLE: Writing zeros KEYWORDS: list-directed output, namelist output DEFECT TYPE: Erratum STATUS: Passed by J3 meeting The standard currently requires a real zero to be written in exponential form when using list-directed or namelist output. QUESTION: Is this requirement intentional or an oversight? ANSWER: The requirement is an oversight, but is not an appropriate problem to fix in Fortran 95 via an interpretation. EDITS: None. SUBMITTED BY: Robert Corbett HISTORY: 99-193 m150 Submitted 99-213r1 m150 approved uc 00-210 m153 Passed by J3 letter ballot 00-268 m154 Failed WG5 letter ballot (N1395 & N1403) WG5/N1452 Suggested revision 01-290r1 m158 Passed by J3 meeting 01-xxx m158 Passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: 000071 TITLE: Character array constructors KEYWORDS: Character, array constructor, zero-size DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: The f95 standard appears to leave the length of zero-sized character array constructors undefined. The penultimate paragraph of clause 4.5 says "The type and parameters of an array constructor are those of the expressions." If there are no elements, then the values of the type parameters might not be defined. The type and kind are always well defined at compile time. However, the length parameter for zero-sized character array constructors is not obviously well-defined, even at run-time. Zero-sized constructors are certainly allowed, as mentioned in the antepenultimate paragraph of clause 4.5: "An empty sequence forms a zero-sized rank-one array." Experimentation with different f90 compilers yields varying results. QUESTION 1: Is the following a valid program and, if so, what len value does it print? program zero write (*,*) len( (/ ('abc', i = 1 , 0) /) ) end QUESTION 2: Is the following a valid program and, if so, what value does it print? program zero_size integer :: n = 0 call sub('abcdefghij', n) contains subroutine sub(string, n) character*(*) :: string integer :: n integer :: i write (*,*) len( (/ (string(:i+2), i = 1 , n) /) ) end subroutine end program zero_size QUESTION 3: Is the following a valid program and, if so, what values does it print for the lengths and for n_calls? program zero_size integer :: n = 0 integer :: n_calls = 0 call sub('abcdefghij', n) write (*,*) 'n_calls = ', n_calls contains subroutine sub(string, n) character*(*) :: string integer :: n integer :: i write (*,*) len( (/ (string(:f(i)), i = 1 , n), 'abcde' /) ) end subroutine sub integer function f(i) f = 2*i + 5 n_calls = n_calls + 1 end function f end program zero_size QUESTION 4: Is this character array constructor valid? (/ ('ABC'(:J/2), J=4,2) /) ANSWER: (1) Yes. The length is 3. Clause 4.5 says that "The type and type parameters of an array constructor are those of the expressions." There is no exclusion for s that contribute no elements to the value of the array constructor: thus s that are inside zero-trip implied DO loops still contribute their "type" information. The example array constructor has an that is the character literal 'abc'; this clearly has the character length of 3 and therefore the array constructor has a character length of 3. The description of how an that is an implied DO is handled confuses syntax and semantics: an edit is supplied to clarify this. (2) No, the has an indeterminate character length and so cannot satisfy the requirement for the lengths to be the same. The edits below clarify this situation. (3) No, one has an indeterminate character length and so cannot satisfy the requirement for the lengths to be the same. (4) No, the has an indeterminate character length. EDITS: In clause 4.5, in the paragraph beginning "If an is a scalar expression" [46:1] replace: "an sequence" with "a sequence of elements". [45:38+] Add to end of paragraph: "The character length of an ac-value in an whose iteration count is zero shall not depend on the value of the implied DO variable and shall not depend on the value of an expression that is not an initialization expression." SUBMITTED BY: Richard Maine HISTORY: 98-101 m144 submitted 20 Nov 1997 99-207 m150 additional input 99-217r3 m150 approved uc 00-209 m153 passed by J3 letter ballot m153 duplicated in interp 000071; processing 000016 complete 00-268 m154 Failed WG5 letter ballot (N1395 & N1403) WG5/N1452 Suggested revision 01-291r1 m158 Passed by J3 meeting 01-xxx m158 Passed by J3 letter ballot, as amended ---------------------------------------------------------------------- NUMBER: 000086 TITLE: Definition status requirements for defined operations KEYWORDS: Defined operations DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: 7.1.7 "Evaluation of operations" states "This section applies to both intrinsic and defined operations. Any variable ... used as an operand in an expression shall be defined at the time the reference is executed." (1) Was this particular requirement intended to apply to defined operations? I.e., is the following example program invalid: MODULE m INTERFACE OPERATOR (.cand.) MODULE PROCEDURE default_cand END INTERFACE CONTAINS LOGICAL FUNCTION default_cand(a,b) RESULT(r) LOGICAL,INTENT(IN) :: a,b IF (a) THEN r = b ELSE r = .FALSE. END IF END FUNCTION END PROGRAM example1 USE m LOGICAL :: false = .FALSE. LOGICAL :: undefined PRINT *, false .cand. undefined END (2) If the answer to the question is Yes (and the program is therefore invalid), would the program be standard-conforming if the penultimate line were changed to PRINT *, default_cand(false,undefined) ? (3) 7.1.7 goes on to state "When a structure is referenced, all of the components shall be defined." Does this mean that pointer components must be associated with a defined target? I.e. is the following program non-conforming? MODULE m2 TYPE my_iptr PRIVATE INTEGER,POINTER :: ptr => NULL() END TYPE INTERFACE OPERATOR(.isnull.) MODULE PROCEDURE isnull_myip END INTERFACE CONTAINS LOGICAL FUNCTION isnull_myip(x) TYPE(my_iptr),INTENT(IN) :: x isnull_myip = ASSOCIATED(x%ptr) END FUNCTION END PROGRAM example2 TYPE(my_iptr) a PRINT *,.isnull.a END (4) If the program is not standard-conforming, would changing the penultimate line to "PRINT *,isnull_myip(a)" make it standard-conforming. ANSWER: (1) No, the requirement was not intentional. (2) Not applicable. (3) No, this was a mistake. (4) Not applicable. DISCUSSION: Usage of defined operations is intended to be equivalent to ordinary function references. All of the examples given above are standard-conforming. EDITS: [97:1] Replace "in an expression" with "of an intrinsic operation". {Only require operands to be defined for intrinsic operations.} [97:5] Replace "all of its components" with "it". {A structure may be referenced whenever it is defined.} HISTORY: 00-292 m154 Submitted; Passed by J3 meeting 00-329 m155 Failed J3 letter ballot WG5/N1452 Added answer to questions 2 and 4. 01-297 m158 Passed by J3 meeting 01-xxx m158 Passed by J3 letter ballot, as amended ---------------------------------------------------------------------- NUMBER: 000091 TITLE: Definition of "present" is defective KEYWORDS: present, dummy argument DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Subclause 12.4.1.5 begins with a definition of the term "present": "A dummy argument is present in an instance of a subprogram if it is associated with an actual argument and the actual argument either is a dummy argument that is present in the invoking subprogram or is not a dummy argument of the invoking subprogram." This seems to be defective in that if the actual argument is a dummy argument that is accessed by host association, it is not a dummy argument OF the invoking subprogram, and therefore although it may be "not present" in the procedure of which it is a dummy argument, it is nonetheless "present" in an internal procedure of that procedure. Consider: module M contains subroutine S1 ( A ) integer, optional :: A call S11 contains subroutine S11 call S12 ( A ) end subroutine S11 subroutine S12 ( B ) integer, optional :: B if ( present(B) ) print *, 'B is present' end subroutine S12 end subroutine S1 end module M program P use M, only: S1 call S1 end program P Should this print "B is present" as implied by the above analysis? ANSWER: No, the program should not print anything. DISCUSSION: The lack of consideration of host association in the cited text is accidental; an edit is supplied to correct this oversight. EDITS: [202:43-45] Replace the first sentence of 12.4.1.5 by "A dummy argument or an entity that is host associated with a dummy argument is not <> if the dummy argument (1) is not associated with an actual argument, or (2) is associated with an actual argument that is not present. Otherwise, it is present." [299:4-6] Delete the glossary entry for <> SUBMITTED BY: Van Snyder HISTORY: 01-134 m156 Submitted 01-134r1 m156 Passed unanimously by J3 meeting 01-224r1 m157 Passed by J3 letter ballot WG5-N1395 Failed WG5 letter ballot WG5-N1463 Accept Kurt Hirchert's suggestion with minor edits 01-302 m158 Passed by J3 meeting 01-xxx m158 Passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: 000095 TITLE: Names of functions, results and entry points KEYWORDS: function result, ENTRY DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTIONS: Consider some examples of FUNCTION/RESULT/ENTRY combinations: (1) FUNCTION F() RESULT(F) This is not allowed ([207:8]). (2) ENTRY E() RESULT(E) This is also not allowed ([209:35]). (3) FUNCTION F() RESULT(R) ENTRY E() RESULT(R) This is allowed (implied by the sentence at [209:41-43]). (4) FUNCTION F() ENTRY E() RESULT(F) Does not appear to be disallowed, though why RESULT(F) should be prohibited on the FUNCTION statement but allowed on the ENTRY statement bemuses me. (5) FUNCTION F() RESULT(E) ENTRY E() Does not appear to be disallowed, though why RESULT(E) should be prohibited on the ENTRY statement but allowed on the FUNCTION statement bemuses me. (6) FUNCTION F() ENTRY E() RESULT(R) ENTRY G() RESULT(R) Appears to be (explicitly?) allowed. (7) FUNCTION F() ENTRY E() ENTRY G() RESULT(E) Does not appear to be disallowed, though why RESULT(E) should be prohibited on an ENTRY statement but allowed on another ENTRY statement bemuses me. (8) FUNCTION F() RESULT(R) ENTRY(R) RESULT(F) Does not appear to be disallowed, even though swapping the RESULT clauses would not be allowed. Q1. Is my analysis correct? If not, why? Q2. Does making the function RECURSIVE alter anything? Further, consider the following examples: (9) RECURSIVE FUNCTION F() RESULT(E) ENTRY E() RESULT(R) This appears to be allowed by the usual rules, but I find it hard to interpret "If RESULT is specified in the ENTRY statement and RECURSIVE is specified in the FUNCTION statement, the interface of the function defined by the ENTRY statement is explicit within the function subprogram." ([210:3-5]) (10) FUNCTION F() RESULT(R) ENTRY E() RESULT(F) This appears to be allowed by the usual rules, but I find it hard to interpret "If RESULT is specified, ... all occurrences of the function name in statements in the scoping unit are recursive function references." ([207:30-32]) Q3. Are these allowed? Come to think of it, in what way is passing the function name as an actual argument a "recursive function reference"? The text seems obviously broken whether these are allowed or not. Q4. Should the text be clarified? ANSWER: A1-A3. Only examples (3) and (6) were intended to be valid. A RESULT clause should only name an existing entity when that entity is also an explicitly specified RESULT variable. Edits are supplied to clarify this. A4. Yes, the text should be clarified. Edits are supplied to clarify and correct the text. EDITS: [207:8] Before "." insert "and shall not be the same as the in any ENTRY statement in the subprogram". [207:32] Change "are recursive function references" to "refer to the function itself". [209:35] Change "" to "the in the FUNCTION statement and shall not be the same as the in any ENTRY statement in the subprogram." SUBMITTED BY: Malcolm Cohen HISTORY: 01-285 m158 Submitted 01-285r1 m158 Passed by J3 meeting 01-xxx m158 Passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: 000097 TITLE: Open Scratch File Example KEYWORDS: Open statement, SCRATCH DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: The first example in C.6.2 has the statement OPEN(UNIT=10, STATUS="SCRATCH", PAD="YES") to change the padding for a unit that is currently open. The 6th paragraph of 9.3.4 discusses the use of an OPEN statement where "the file to be connected to the unit is the same as the file to which the unit is connected". It says "If the STATUS= specifier is included in such an OPEN statement, it shall be specified with a value of OLD." Note this wording was introduced in f90 interp 186, which discusses it. The above-cited OPEN statement from C.6.2 appears to violate this requirement. Is the example in error? ANSWER: Yes, this is an error in the example. EDITS: [322:38] "SCRATCH" -> "OLD" HISTORY: 01-345 m158 Passed by J3 meeting 8-1 01-xxx m158 Passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: F90/000164 TITLE: Use of ONLY with multipart definitions KEYWORDS: ONLY, module, derived type DEFECT TYPE: Clarification STATUS: Passed by J3 meeting QUESTION: Sections 11.3.1 and 11.3.2, among others, describe how accessibility of data objects, derived type definitions, etc. can be controlled via the ONLY clause of the USE statement and via the PUBLIC and PRIVATE accessibility attributes/statements. But these sections do not describe what happens when a definition consists of multiple parts and only some of the parts have their accessibility controlled. Examples include, but are not limited, to the following: Example 1: MODULE MOD INTEGER, PARAMETER :: MAX_SIZE = 100 INTEGER, DIMENSION(MAX_SIZE) :: ARRAY END MODULE PROGRAM MAIN USE MOD, ONLY: ARRAY ... END PROGRAM QUESTION 1a) Since the declaration of ARRAY depends on the value of MAX_SIZE, is it valid to only allow access to ARRAY? QUESTION 1b) Is the array constructor for ARRAY, for example, accessible to the main program? Example 2: MODULE MOD TYPE INNER INTEGER I END TYPE TYPE OUTER INTEGER K TYPE(INNER) COMP END TYPE END MODULE PROGRAM MAIN USE MOD, ONLY: OUTER ... END PROGRAM The derived type OUTER in module MOD has a component of derived type INNER. However, when the main program accesses the module, it restricts access to only derived type OUTER. QUESTION 2a) Since OUTER depends on the definition of INNER, is it valid to only allow access to OUTER? QUESTION 2b) If it is not valid, is it only an error if something in the main program actually tries to use OUTER? QUESTION 2c) Can you write a structure constructor for OUTER in the main program? QUESTION 2d) If it is valid, can component I of substructure COMP be referenced? Example 3: MODULE MOD TYPE DEF INTEGER K REAL R END TYPE TYPE(DEF) VAR END MODULE PROGRAM MAIN USE MOD, ONLY: VAR ... END PROGRAM In this example, only the variable VAR from the module is accessible; its type is not. QUESTION 3a) Is this (example 3) valid? QUESTION 3b) If it is valid, can only the structure name VAR be referenced or can its components also be referenced? QUESTION 3c) If only the structure name VAR can be referenced, what is the meaning when the structure name is included in a namelist object list for input and/or output? Example 4: MODULE MOD INTEGER, PARAMETER :: MAX_SIZE = 100 INTEGER, DIMENSION(MAX_SIZE) :: ARRAY PRIVATE MAX_SIZE END MODULE PROGRAM MAIN USE MOD ... END PROGRAM Another way to limit access to items in modules is via the PRIVATE attribute/statement. QUESTION 4a) Since the declaration of ARRAY depends on the value of MAX_SIZE, is it valid to only allow access to ARRAY? QUESTION 4b) Is the array constructor for ARRAY, for example, accessible to the main program? ANSWER: 1a) Yes, ARRAY is accessible, including its size (via the SIZE intrinsic), even though MAX_SIZE is not accessible. 1b) An array constructor of size 100 may be used in an assignment statement for ARRAY. 2a) Yes, it is valid to access only OUTER and declare objects of type OUTER. 2b) Not applicable. 2c) Yes, the structure constructor may be used in the main program. For example, TYPE(OUTER) X,Y X%COMP%I = 65 Y = OUTER(13,X%COMP) 2d) Yes, component I of component COMP may be referenced. 3a) Yes, there is no requirement that a type name be accessible for an entity of that type to be accessible. 3b) Both VAR and its components may be referenced. 3c) Not applicable. These questions were resolved by interpretation 85, which made a clarifying edit to 14.1.2.5. 4a) Yes, it is valid to allow access only to ARRAY. 4b) ARRAY is accessible, including its size (via the SIZE intrinsic), so an array constructor of size 100 may be used in an assignment statement for ARRAY. EDITS: None. SUBMITTED BY: Larry Rolison HISTORY: 94-038 m128 submitted 01-312r2 m158 Passed by J3 meeting 01-xxx m158 Passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: F90/000209 TITLE: STOP|PAUSE in I/O statement KEYWORDS: STOP, PAUSE DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: Section 9.7. May a function referenced in an I/O statement execute a STOP or PAUSE statement? If STOP statements are permitted, what is the state of the file at the end of execution? ANSWER: (a) The PAUSE statement has been deleted from Fortran 95, so a standard-conforming program shall not contain such a statement. (b) No, a STOP statement may not be executed in this situation. Executing a STOP statement causes normal termination of execution, which closes all files (9.3.5), and this is equivalent to executing a CLOSE statement, which is prohibited by 9.7. A clarifying edit is supplied. EDITS: [160:20] after "statement" insert "or STOP statement". SUBMITTED BY: Robert Paul Corbett HISTORY: submitted Mar. 13, 1996 (first appeared in 96-006r2) WG5/N1452 Suggested answers (two alternatives) 01-2931r1 m158 Passed by J3 meeting 01-xxx m158 Passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: F90/000211 TITLE: Multiple MODULE PROCEDURE specs KEYWORDS: MODULE PROCEDURE, generic interface, USE association DEFECT TYPE: Erratum STATUS: Passed by J3 meeting WG5/N1176 (X3J3/96-007) says [194:21-23]: "Constraint: A in a shall not be one which previously had been specified in any with the same generic identifier in the same specification part." QUESTION: 1. Is it correct that this constraint does not preclude the following? MODULE foo1 INTERFACE generic_spec MODULE PROCEDURE proc1 END INTERFACE CONTAINS SUBROUTINE proc1 END SUBROUTINE proc1 END MODULE foo1 MODULE foo2 USE foo1 INTERFACE generic_spec MODULE PROCEDURE proc1 END INTERFACE END MODULE foo2 Although foo2 clearly violates the uniqueness conditions in 14.1.2.3, it seems that it does not violate a Constraint. (Actual compilers do not seem to detect this form of violation of 14.1.2.3 at compile-time.) 2. If the answer to (1) is YES, wouldn't it be sensible to extend that constraint to cases where a "previous" specification of in a with the same generic identifier in the specification part of an accessible module had occurred, _and_ that and generic-spec have PUBLIC accessibility? Probably the wording might be quite complicated because of the possibility of s if FOO1 and s in FOO2, but the essence should be straightforward... The situation in (1) is very similar to the following example, which _is_ detected as erroneous by the compilers I tried: MODULE foo1 CONTAINS SUBROUTINE proc1 END SUBROUTINE proc1 END MODULE foo1 MODULE foo2 USE foo1, ONLY: proc1 USE foo1, ONLY: proc2 => proc1 INTERFACE generic_spec MODULE PROCEDURE proc1 MODULE PROCEDURE proc2 END INTERFACE END MODULE foo2 In both cases, the specific s (and the ) are accessible in MODULE foo2, and the interfaces are explicit anyway. ANSWER: (1) Yes, this constraint does not apply to the example. Nor does 14.1.2.3, which only applies between pairs of specific procedures - there is only one specific procedure in this example. Note: However, processors are required to diagnose violations of the requirements of 14.1.2.3 - see 1.5 item 6. (2) Yes, the constraint should be fixed to prohibit the examples. Note: As it stands, the second example is not prohibited either by the constraint or by 14.1.2.3. EDITS: [194:21-23] Replace with "Constraint: A in a shall not specify a procedure that is specified previously in any in any accessible interface block with the same generic identifier." SUBMITTED BY: Michael Hennecke HISTORY: submitted Apr. 12, 1996 (first appeared in 96-006r2) WG5/N1452 Suggested answer (two alternatives) 01-294r1 m158 Passed by J3 meeting 01-xxx m158 Passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: F90/000212 TITLE: EQUIVALENCE of Data Objects of Different Types or Kinds KEYWORDS: EQUIVALENCE limitations DEFECT TYPE: Clarification STATUS: Passed by J3 meeting Section 5.5.1 acknowledges that it is possible to construct equivalences between data objects of different types or kinds: "If equivalenced objects have differing type or type parameters, the EQUIVALENCE statement does not cause type conversion or imply mathematical equivalence." However, section 5.5.1 also has severe restrictions on equivalences between data objects of differing types and kinds. Following rule R547, there are a series of constraints. Constraints 3 through 6 read: Constraint: If an is of type default integer, default real, double precision real, default complex, default logical, or numeric sequence type, all of the objects in the equivalence set must be these types. Constraint: If an is of type default character or character sequence type, all of the objects in the equivalence set must be of these types. Constraint: If an is of a derived type that is not a numeric sequence or character sequence type, all of the objects in the equivalence set must be of the same type. Constraint: If an is of an intrinsic type other than default integer, default real, double precision real, default complex, default logical, or default character, all of the objects in the equivalence set must be of the same type with the same kind type parameter value. Question 1) Why are these constraints in the standard? What useful purpose do they serve? What problems do they prevent or solve? Question 2) Could a standard-conforming processor relax or eliminate one or more of these constraints, as an extension, without sacrificing full conformance to the standard? Question 3) Can a data object of sequence derived type be equivalenced to another data object of a different sequence derived type? Question 4) Assume that a processor has among its intrinsic types INTEGER (1) (8 bits), INTEGER (2) (16 bits), and INTEGER (4) (32 bits). Given the following definitions, is the EQUIVALENCE statement standard-conforming? TYPE T1 SEQUENCE INTEGER (1) I1_ARRAY (36) END TYPE TYPE T4 SEQUENCE INTEGER (4) I4_ARRAY (9) END TYPE TYPE (T1) OBJECT_1 TYPE (T4) OBJECT_4 EQUIVALENCE (OBJECT_1, OBJECT_4) Question 5) Can an object of sequence derived type be equivalenced to an array of intrinsic type? Question 5a) Assume the definitions of question 4. Is the following EQUIVALENCE statement standard conforming? INTEGER (4) :: I4_ARRAY_9 (9) EQUIVALENCE (OBJECT_1, I4_ARRAY_9) Question 6) Can an object of sequence derived type be equivalenced to a scalar of intrinsic type? ANSWER: Question 1: The constraints are there for portability (section 1.1) since different implementations may use different amounts of storage for these objects. Question 2: Such an extension is permitted, but the processor must provide the capability to detect this (see section 1.5). Question 3: Yes, a numeric sequence structure may be equivalenced to another numeric sequence structure and a character sequence structure may be equivalenced to another character sequence structure (see note 5.28). Question 4: No, this is not standard-conforming, because either INTEGER(1) or INTEGER(4) or both are non-default integers (see fourth constraint above). Question 5: Yes, a numeric sequence structure may be equivalenced to an array of default integer type, default real type, double precision real type, default complex type, or default logical type, and a character sequence structure may be equivalenced to an array of default character type (see note 5.28). Question 5a: No, this is not standard-conforming, because either INTEGER(1) or INTEGER(4) or both are non-default integers (see fourth constraint above). Question 6: Yes, a numeric sequence structure may be equivalenced to a scalar of default integer type, default real type, double precision real type, default complex type, or default logical type, and a character sequence structure may be equivalenced to a scalar of default character type (see note 5.28). EDITS: None SUBMITTED BY: Craig Dedo HISTORY: submitted Jan. 23, 1996 (first appeared in 96-006r2) WG5-N1456 draft answer 01-307 m158 Passed by J3 meeting 10-2 01-xxx m158 Passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: JP-04 TITLE: Construction of derived-type values KEYWORDS: component, pointer, constructor DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: JP-4) 4.4.4 Construction of derived-type values Before NOTE 4.34: "Where a component in the derived type is a pointer, the corresponding constructor expression shall evaluate to an object that would be an allowable target for such a pointer in a pointer assignment statement (7.5.2)." Change `an object' to `a result value'. A value of an expression can not be an object, by definition. ANSWER: An edit is required but the proposed edit is not quite correct, because the expression might yield a null pointer. EDITS: Replace [45:7-9] by "Where a component in the derived type is a pointer, the corresponding constructor expression shall be an allowable for such a pointer in a pointer assignment statement (7.5.2)." SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot WG5-N1456 Accept Steidel's comment 01-308 m158 Passed by J3 meeting 01-xxx m158 Passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: JP-05 TITLE: Construction of array values KEYWORDS: constructor DEFECT TYPE: Interpretation STATUS: Passed by J3 meeting QUESTION: JP-5) 4.5 Construction of array values, "The ac-do-variable of an ac-implied-do that is in another ac-implied-do shall not appear as the ac-do-variable of the containing ac-implied-do." This sentence should be a Constraint. ANSWER: No. The requirement should be made a constraint in the next standard. It should remain a simple requirement in Fortran 95 to avoid invalidating existing implementations. EDITS: None SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot WG5-N1463 Accept Henry's and Jon's comments 01-303r1 m158 Passed by J3 meeting 01-xxx m158 Passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: JP-08 TITLE: Type declaration statements KEYWORDS: character length DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: JP-8) 5.1 Type declaration statements After NOTE 5.3 [49:8]: "If a length-selector (5.1.1.5) is a nonconstant expression, ..." Change `length-selector' to `char-selector', `char-len-selector' or `character-length'. ANSWER: Agreed, but we think that "char-len-param-value" would be a better replacement text. EDITS: [49:9] Replace "" by "". SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot WG5-N1456 Accept Zongaro's comment 01-309r1 m158 Passed by J3 meeting 01-xxx m158 Passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: JP-16 TITLE: Multiple occurrence of namelist-group-name in NAMELIST statement KEYWORDS: namelist DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: JP-16) 5.4 2nd paragraph after R545 and constraints (Page 66 Line 11) states that: "Any namelist-group-name may occur in more than one NAMELIST statement in a scoping unit." Can a namelist-group-name occur more than once in one NAMELIST statement ? Is the following NAMELIST statement standard conforming ? NAMELIST /NLIST/ A, B /NLIST/ C, D If this is standard conforming, is it the same as the following ? NAMELIST /NLIST/ A, B, C, D ANSWER: Yes, the rules should be analogous to those for named common blocks at [69:16-19]. EDITS: [66:11] Replace "in more than one NAMELIST statement" by "more than once in the NAMELIST statements" SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot WG5-N1456 Accept Hirchert's comment 01-310r1 m158 Passed by J3 meeting 01-xxx m158 Passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: JP-17 TITLE: Multiple occurrence of namelist group object in namelist group KEYWORDS: NAMELIST DEFECT TYPE: Erratum STATUS: Passed by J3 meeting QUESTION: JP-17) 5.4 3rd paragraph after R545 and constraints states that: "A namelist group object may be a member of more than one namelist group." Can a namelist group object occur more than once in one namelist group? Is the following NAMELIST statement standard conforming? NAMELIST /NLIST/A,B,A ANSWER: No. EDITS: [66:14] Add new sentence at the end of the line: "A namelist group object shall not appear more than once in a single namelist group." SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot 01-300 m158 Passed by J3 meeting 01-xxx m158 Passed by J3 letter ballot ---------------------------------------------------------------------- NUMBER: JP-31 TITLE: Signs of literal constants KEYWORDS: sign, literal DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: JP-31) The fourth sentence of 10.8 and sixth sentence of 10.9: "Each value is either a null value or one of the forms: c r*c r* where c is a literal constant or a nondelimited character constant and r is an unsigned, nonzero, integer literal constant." "a literal constant" should be "an optionally signed literal constant" ANSWER: Add the phrase, "if integer or real" to that last phrase above. EDITS: [175:5] Replace "constant or" by "constant, optionally signed if integer or real, or" [178:40] Replace "constant and" by "constant, optionally signed if integer or real, and" Note for F2000: The phrase "literal constant" [73:34] in F95 is not the BNF term but F95 doesn't say if "literal constant" is signed. SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot WG5-N1463 Update the edit 01-304 m158 Passed by J3 meeting 01-xxx m158 Passed by J3 letter ballot ----------------------------------------------------------------------