J3/97-243 Date: 15 October 1997 To: J3 From: Larry Rolison Subject: Interpretation Request: Optional Intrinsic Function Arguments NUMBER: 7 TITLE: Optional intrinsic function arguments KEYWORDS: intrinsic function, argument - optional DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress 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: EDITS: SUBMITTED BY: Larry Rolison HISTORY: J3/97-243 m143 submitted Addendum: A history of how this interp progressed: Yukimasa Yoshida sent a message to the interpretation request bulletin board noting that some of the actual arguments to intrinsic functions should not be allowed to be optional dummy arguments. Since I could not find an interpretation request in the premeeting papers for meeting 121, I submitted paper X3J3/92-058 (121-LRR-5) with his message and added that the ISHFTC intrinsic function should be added to the list supplied by Mr. Yoshida. Given the hand-written notes on my paper copy of 92-058, the /PROC subgroup apparently worked on my original paper and recast it as 92-094 with the proposed edit: The restriction: "The corresponding actual argument must not be an optional dummy argument." should be added to the text describing these optional arguments mentioned above for CMPLX, INDEX, ISHFTC, MAX, MIN, SCAN, and VERIFY. [ Historical aside: While looking through the minutes for this meeting, I noticed that this was the meeting where Richard Maine joined the committee and Walt rejoined the committee (to work on a validation suite for Fortran 90). Under Reports and Comments from Members, Andrew Tait expressed concern about the copyright situation. Some topics just never die, do they? Mind you, meeting 121 was in May, 1992. ] The minutes for the last day of the meeting show that Hirchert/Hoffert moved to adopt 92-094, but that it and several others were withdrawn. There are notes as to why some of the others were withdrawn but not for 92-094. I have no personal notes from this meeting as I did not attend. WG5 paper N786A authored by John Reid is a proposal for the Victoria meeting to create a corrigendum for the Fortran 90 standard. As part of this proposal, BSI suggested the following change with respect to an optional dummy argument being passed to optional argument of an intrinsic procedure: 179/38+. Add: (5) If it is an array, it must not be supplied as an actual argument to an elemental procedure unless an actual argument that is present is an array of the same rank. Discussion: It was intended that the rank of an expression should never vary. Note that this text again just focuses on the cases where rank causes a problem. I don't know the precise contents of WG5 paper N815A since I did not copy it to a local directory and it seems to no longer be available on the WG5 server (at least not through Richard's mirror), but presumably it is a refinement of N786A done at the Victoria meeting. X3J3 paper 92-156a added the example to the Discussion section (or repeated it from N815A) and this paper also has the minor edit following the addition of part (5) to the list. The minutes of meeting 122 show that the paper was approved by a vote of 20-3. ------------------------------------------------------------------------------- >From a coworker here at SGI/CRI: The restriction should be that they can't use OPTIONAL arguments not present, not just OPTIONALS. In other words, it should be OK to have INDEX(a, b, back) with BACK optional, provided that BACK is present if the intrinsic is evaluated. ---------------------------------------------------------------------------- Larry Rolison lrr@cray.com Cray Research, A Silicon Graphics Company 655F Lone Oak Drive Eagan, MN 55121 ----------------------------------------------------------------------------