From jwagener@trc.amoco.com Wed Dec 9 07:54:36 1992 Received: from noc.msc.edu by dkuug.dk with SMTP id AA21873 (5.65c8/IDA-1.4.4j for ); Wed, 9 Dec 1992 20:55:02 +0100 Received: from uc.msc.edu by noc.msc.edu (5.65/MSC/v3.0.1(920324)) id AA03376; Wed, 9 Dec 92 13:54:59 -0600 Received: from [149.180.11.2] by uc.msc.edu (5.65/MSC/v3.0z(901212)) id AA15748; Wed, 9 Dec 92 13:54:50 -0600 Received: from trc.amoco.com (apctrc.trc.amoco.com) by netserv2 (4.1/SMI-4.0) id AA28431; Wed, 9 Dec 92 13:54:44 CST Received: from crmac1 by trc.amoco.com (4.1/SMI-4.1) id AA18141; Wed, 9 Dec 92 13:54:36 CST Date: Wed, 9 Dec 92 13:54:36 CST Message-Id: <9212091954.AA18141@trc.amoco.com> From: Jerrold L. Wagener To: SC22WG5@dkuug.dk Subject: S20.123, items 31-60 X-Charset: ASCII X-Char-Esc: 29 NUMBER: 000031 TITLE: Overloaded Implied-DO Variable Names KEYWORD: implied-Do variable, DATA statement DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Section 14.1.3. states: The name of the 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. Is the following in error since J has type character and therefore does not have type integer? CHARACTER J INTEGER A(10) DATA (A(J), J=1,10) /10*5/ Is the following valid because, although J is a named constant, it has type integer? INTEGER J PARAMETER (J=5) INTEGER A(10) DATA (A(J), J=1,10) /10*5/ Is the following valid? TYPE (ITYPE) CHARACTER FIELD1 INTEGER FIELD2 END TYPE INTEGER A(10) DATA (A(ITYPE), ITYPE=1,10) /10*5/ If ITYPE were a variable it would have type integer and this would be valid. Does the fact that it is the name of a derived type cause a conflict? The second sentence cited above appears to allow EXTERNAL J INTEGER A(10) DATA (A(J), J=1,10) /10*5/ The EXTERNAL statement declares J to be a global name. If J is a subroutine it has no type, so the presence of the EXTERNAL statement is irrelevant. If J were a function, then it must be type integer for the presence of J in the DATA statement to be valid. Question 1: Is the Fortran 90 standard intentionally extending the FORTRAN 77 standard with respect to implied-DO variables in DATA statements? Did the Fortran 90 standard intentionally delete the material about COMMON block names in section 18.2.7 of X3.9-1978? Question 2: Are the conclusions and interpretations above correct or incorrect? If incorrect, for what specific reasons are they incorrect? Question 3: Are the examples above standard conforming program fragments? If not, what are the specific reasons? Question 4: Are the rules for implied-DO variables in DATA statements and array constructors the same? If they are not exactly the same, provide examples which illustrate the differences. ANSWER: It was intended that the rules for implied-DO variables be similar to those in X3.9-1978. An edit to section 14.1.3 of ISO/IEC 1539:1991 clarifies these rules. The answers to your questions are: 1. Fortran 90 extended the rules for implied-DO variables in DATA statements in two ways: a) The type of an implied-DO variable must be integer but need not be default integer. b) FORTRAN 77 allowed the name of the statement entity also to be the name of a (scalar) variable or COMMON block (X3.9-1978, section 18.2.7) in (i.e., appearing in) the program unit containing the DATA statement or statement function statement. Fortran 90 allows the name of the statement entity also to be the name of a scalar variable or COMMON block appearing in or accessible from the enclosing scope (section 14.1.3 of ISO/IEC 1539-1991, with the changes in the EDITS section, below). 2. The detailing of the conclusions and justifications given below in (3) answer this. 3. The first example is in error because J is of type character and R537 requires integer type. The second example is in error. J is of type integer as required by R537, but the edit to section 14.1.3 prohibits the name of a statement entity also being the name of a constant in the same scoping unit. The third example is in error. The edit to section 14.1.3 prohibits the name of a of a statement entity also being the name of a derived type. The fourth example is in error. The edit to section 14.1.3 prohibits the name of a statement entity also being the name of an external function or subroutine. 4. The rules for implied-DO variables in DATA statements and in array constructors, with respect to typing and scope, are the same. REFERENCES: ISO/IEC 1539:1991, sections 5.2.9, 6.2.1, 14.1.2, 14.1.3. X3.9-1978, section 18.2.7 EDITS: Replace the last paragraph of section 14.1.3 with the following two paragraphs: Except for a common block name or a scalar variable name, a name that identifies a global entity or local entity of class 1 (14.1.2) accessible in the scoping unit of a statement must not be the name of a statement entity of that statement. Within the scope of a statement entity, another statement entity must not have the same name. 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. Elsewhere in the scoping unit, including parts of the statement outside the scope of the statement entity, the name is interpreted as that of the global or local entity. SUBMITTED BY: L. R. ROLISON, 120-LRR-2 (120.027) LAST SIGNIFICANT CHANGE: 92-11-10, new response approved at meeting 123 HISTORY: 1st response - 120-RRR-1A (92.069a) -- all prohibited Griffiths' complaint (92.49, p. 11ff) 2nd response (92.112) -- all allowed Email discussion (92.132, #4, 5, 32, 33, 38, 39, 49) WG5 suggests F77 restrictions (92.136, N815-7) 3rd response (92.167a) drafted by DATA subgroup at meeting 122; final action deferred due to 2 week rule Improved edits suggested by Janice Shepherd (private communication) 4th response (92-229b) approved at meeting 123 (22-1) ----------------------------------------------------------------------- NUMBER: 000032 TITLE: Implicit Declaration of a Derived Type KEYWORDS: derived type, IMPLICIT statement DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Is the following program standard conforming? IMPLICIT TYPE(T1) (A-D) ! Note IMPLICIT range is A-D. TYPE T1 SEQUENCE CHARACTER*10 NAME INTEGER EMP_NUMBER END TYPE T1 A1%NAME='FRED' ! A1 is implicitly declared to be ! of type T1. ... CONTAINS SUBROUTINE INNER IMPLICIT TYPE(T1) (D) ! D now overrides IMPLICIT for D ! in host. TYPE T1 INTEGER WIDTH INTEGER HEIGHT END TYPE T1 D%WIDTH = 10 ! No problem here, D is implicitly ! declared with the T1 that is ! defined in INNER. CALL OUTSIDE(C) ! Is this an error? ... Is a reference to A1 (declared in the host) from inside INNER permitted in this example? ANSWER: Yes, the example is standard conforming. Discussion: Components of A1 can also be referred to from inside INNER. While the derived type T1 from the host scoping unit is inaccessible inside the internal routine INNER, there is no reason why data entities of this derived type that are accessible cannot be referred to. The implicit mapping for the letter C is not specified within the internal routine INNER. So, the implicit mapping is that of the host routine. In the host routine the letter C is mapped to derived type T1 of the host. Therefore the variable C is implicitly declared to be of type T1 from the host. The components of the variable C, C%NAME and C%EMP_NUMBER, can also be referred to in INNER. The following edits clarify the standard with regard to these questions. REFERENCES: ISO/IEC 1539:1991 (E) section 5.1.1.7, 5.3, 12.1.2.2.1 EDIT(S): 1. In the first paragraph of 5.1.1.7, change "is specified" to "is explicitly declared". 2. In paragraph 5 of 5.3 after "provided the mapping is not null.", insert the new sentence: "Note that the mapping can be to a derived type that is inaccessible in the local scope if the derived type is accessible to the host scope." 3. In paragraph 3 of 12.1.2.2.1 after "prior to the DATA statement.", insert a new paragraph: "If a derived type name of a host is inaccessible, data entities of that type or subobjects of such data entities still can be accessible." SUBMITTED BY: L. R. Rolison, 120-LRR-5 (120.030) LAST SIGNIFICANT CHANGE: 1992 11 10, revised content HISTORY: 120-TMRE-2 (120.075) Questioned by 92-035, 92-049(p14), 92-050(p4) Revised at meeting 121 but rejected Revised response proposed in 92-280, approved by unanimous consent at meeting 123 ----------------------------------------------------------------------- NUMBER: 000033 TITLE: Interface Blocks with the Same Name in a Program KEYWORDS: generic interface blocks, module, USE statement DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Question 1: In the following program, both interface blocks have the same generic name and thus might be considered to be merged into a single generic interface block. Is function F1 (from MODULE MOD_1) accessible to the program but FUNCTION F2 (from MODULE MOD_2) hidden? MODULE MOD_1 PUBLIC INT_1 INTERFACE INT_1 ! Generic interface - PUBLIC. INTEGER FUNCTION F1(K) INTEGER K END FUNCTION END INTERFACE ... END MODULE MOD_1 MODULE MOD_2 PRIVATE INT_1 INTERFACE INT_1 ! Generic interface, same name - PRIVATE INTEGER FUNCTION F2(L) LOGICAL L END FUNCTION END INTERFACE ... END MODULE MOD_2 PROGRAM EXAMPLE_1 USE MOD_1; USE MOD_2 ! Program accesses both modules. ... END Question 2: If the following module is added to the above example and the USE statement in the main program is changed to "USE MOD_1; USE MOD_2; USE MOD_3", is the resulting program standard conforming? MODULE MOD_3 PUBLIC INT_1 INTERFACE INT_1 ! Generic interface, same name - PUBLIC. INTEGER FUNCTION F3(L) LOGICAL L END FUNCTION END INTERFACE ... END MODULE MOD_3 Question 3: If the program and modules shown above are altered so that module MOD_2 USEs MOD_1 and the program EXAMPLE_1 only USEs MOD_2 directly, is this an example of a standard conforming program? If it is standard conforming, does the program have access to function F1 but not F2? ANSWER 1: No, the program is not standard conforming. ANSWER 2: Yes, the program is standard conforming. ANSWER 3: Yes, the program is standard conforming. Both F1 and F2 are accessible. Discussion: Because the name INT_1 is private in the module MOD_2, the interface for the function F2 is accessible in the program EXAMPLE_1, but NOT the generic name INT_1. Therefore, the two interface blocks are NOT merged into a single generic interface block. The function F1 is, therefore, accessible in the program EXAMPLE_1 by either its specific name F1 or the generic name INT_1; the function F2, on the other hand is accessible only by its specific name F2. This shows that the function F2 (from MODULE MOD_2) does not share the same generic name, INT_1, as the function F1 (from MODULE MOD_1). When the example is modified as specified by Question 2, the new module MOD_3 defines a new interface block INT_1, which will be combined with the identically named interface block from module MOD_1. In the program EXAMPLE_1 the generic name INT_1 has the two specific names F1 and F3. However, since F2 is not part of the combined generic interface block the fact that F2 and F3 have the same dummy argument and result characteristics is of no significance, and the program is standard conforming. When the example is modified as specified by Question 3, within module MOD_2 the two generic interface blocks are combined into a single interface block. However, since INT_1 is declared to be private within module MOD_2 only the specific names of the functions F1 and F2 are accessible to program units using MOD_2. Therefore, both the function F1 and F2 are accessible within the program EXAMPLE_1, but only by their specific names. REFERENCES: EDIT(S): None. SUBMITTED BY: L. R. Rolison, 120-LRR-6 (120.031) HISTORY: 120-TMRE-3 (120.076) Included into S20 as three items (33-35). Recombined in 92-308. Approved by unanimous consent at meeting 123. ----------------------------------------------------------------------- NUMBER: 000034 TITLE: Interface Blocks with the Same Name in a Program - II KEYWORDS: generic interface blocks, module, USE statement DEFECT TYPE: Interpretation STATUS: - subsumed by item 33 - QUESTION: If the following module is added to the example given in NUMBER 000033, and the USE statement in the main program is changed to "USE MOD_1, MOD_2, MOD_3", is the resulting program standard conforming? MODULE MOD_3 PUBLIC INT_1 INTERFACE INT_1 ! Generic interface, same name - PUBLIC. INTEGER FUNCTION F3(L) LOGICAL L END FUNCTION END INTERFACE ... END MODULE MOD_3 ANSWER: Yes, but not for the reason implied by the question. Discussion: The answer in NUMBER 000033 shows that the function F2 (from MODULE MOD_2) does not share the same generic name, INT_1, as the function F1 (from MODULE MOD_1). The new module MOD_3 defines a new interface block INT_1, which will be combined with the identically named interface block from module MOD_1. In the program EXAMPLE_1 the generic name INT_1 has the two specific names F1 and F3. However, since F2 is not part of the combined generic interface block the fact that F2 and F3 have the same dummy argument and result characteristics is of no significance, and the program is standard conforming. REFERENCES: EDIT(S): None. SUBMITTED BY: L. R. Rolison, 120-LRR-6 (120.031) Part 2 HISTORY: 120-TMRE-3 (120.076) ----------------------------------------------------------------------- NUMBER: 000035 TITLE: Interface Blocks with the Same Name in a Program - III KEYWORDS: generic interface block, module, USE statement DEFECT TYPE: Interpretation STATUS: - subsumed by item 33 - QUESTION: If the program and modules shown in NUMBER 000033 are altered so that module MOD_2 USEs MOD_1 and the program EXAMPLE_1 only USEs MOD_2 directly, is this an example of a standard conforming program? If it is standard conforming, does the program have access to function F1 but not F2? ANSWER: Yes, the program is standard conforming. Discussion: Within module MOD_2 the two generic interface blocks are combined into a single interface block. However, since INT_1 is declared to be private within module MOD_2 only the specific names of the functions F1 and F2 are accessible to program units using MOD_2 (c.f. NUMBER 000033). Therefore, both the function F1 and F2 are accessible within the program EXAMPLE_1, but only by their specific names. REFERENCES: EDIT(S): None. SUBMITTED BY: L. R. Rolison, 120-LRR-6 (120.031) Part 3 HISTORY: 120-TMRE-3 (120.076) ----------------------------------------------------------------------- NUMBER: 000036 TITLE: Pointer to an Assumed-size Array KEYWORDS: pointer, assumed-size array, pointer assignment statement DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Is a pointer assignment statement of the form: PTR => A where A is an assumed-size array, standard conforming? ANSWER: No. This is prohibited by section 6.2.1, second paragraph, second sentence. REFERENCES: ISO/IEC 1539:1991 (E) section 6.2.1 EDIT(S): None. SUBMITTED BY: L. R. Rolison, 120-LRR-7 (120.032) HISTORY: 120-RRR-2A (120.087A) Approved in ballot 92-182 ----------------------------------------------------------------------- NUMBER: 000037 TITLE: Use of Array Sections in Pointer Assignment Statements KEYWORDS: pointer assignment statement, array sections, pointer DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: If A is an assumed-size array: Is "PTR => A(:N)" standard conforming? Are "PTR => A(:)" and "PTR => A(N:)" standard conforming? ANSWER: "PTR => A(:N)" is standard conforming because A(:N) is a valid array section. Forms "PTR => A(:)" and "PTR => A(N:)" are not standard conforming because the array sections are prohibited by the second constraint after R621. REFERENCES: ISO/IEC 1539:1991 (E) section 6.2.2 EDIT(S): None. SUBMITTED BY: L. R. Rolison, 120-LRR-7 (120.032) HISTORY: 120-RRR-2A (120.087A) Approved in ballot 92-182 ----------------------------------------------------------------------- NUMBER: 000038 TITLE: Same Interface Body in Multiple Generic Interface Blocks KEYWORDS: interface body, generic interface blocks, scoping unit DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Part 1. Is the following example standard conforming? That is, can the same interface body exist in multiple generic interface blocks that are all accessible from a single scoping unit? MODULE MOD_1 INTERFACE RED SUBROUTINE CMN(K) INTEGER K END SUBROUTINE SUBROUTINE S(X) REAL X END SUBROUTINE END INTERFACE END MODULE MODULE MOD_2 INTERFACE BLUE SUBROUTINE SS(Y) REAL Y END SUBROUTINE SUBROUTINE CMN(K) INTEGER K END SUBROUTINE END INTERFACE END MODULE PROGRAM EXAMPLE_1 USE MOD_1; USE MOD_2 INTEGER M ... CALL RED(M) ... CALL BLUE(M) ... END PROGRAM Part 2. If the names are removed from the interface blocks in both modules, thus making them nongeneric, and the subroutine calls in program EXAMPLE_1 replaced by "CALL CMN(M)", is the resulting program standard conforming? That is, may a procedure interface description occur in multiple nongeneric interface blocks that are accessible to a given scoping unit and may the program unit reference that procedure? ANSWER: Part 1. No. The example is not standard conforming. Part 2. No. Discussion: The last sentence of the second paragraph of 12.3.2.1 states A procedure must not have more than one explicit specific interface in a given scoping unit. In the example the subroutine CMN has two specific interfaces, one from each module in the program EXAMPLE_1 which is forbidden. The program could be made standard conforming by making the name CMN private in one or both modules or by adding a rename or only option to one of the USE statements. REFERENCES: ISO/IEC 1539:1991 (E) section 12.3.2.1 EDIT(S): None. SUBMITTED BY: L. R. Rolison, 120-LRR-8 (120.033) HISTORY: Original interpretation in 120-TMRE-4 (120.077) Questioned in X3J3/92-131 Approved as X3J3/92-174 at meeting 122 by unanimous consent Edit approved in 92-267r at meeting 123 -------------------------------------------------------------------------- NUMBER: 000039 TITLE: Association of a Pointer Actual Argument with a Dummy Argument KEYWORDS: pointer, actual argument, dummy argument, argument association DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: When a pointer is passed as an actual argument, is the intent of the standard as follows: Dereferencing of the pointer is dependent on the interface of the called procedure. That is, if the dummy argument is known to be a pointer (with matching type, etc.) then the pointer actual argument is NOT dereferenced - the pointer itself is passed. Conversely, if the dummy argument is unknown or is known to not be a pointer then the pointer dummy argument is dereferenced so that its target is passed (possibly through a temporary)? If yes, please quote the text that specifies the meaning of passing a pointer as an actual argument. ANSWER: Section 5.1.2.4.3 indicates that a pointer actual argument may be associated with either a pointer dummy argument or a nonpointer dummy argument. The semantics of a pointer actual argument associated with a pointer dummy argument are specified in section 12.4.1.1. When a pointer actual argument is associated with a nonpointer dummy argument, the actual argument's associated target object becomes associated with the dummy argument. Section 7.1.4.1 states If a pointer appears as a primary in an intrinsic operation or a defined operation in which it corresponds to a nonpointer dummy argument, the associated target object is referenced. Discussion: The standard does not specify implementation details. A valid implementation would allow passing a descriptor when a pointer actual argument is associated with a pointer dummy argument and a temporary when the dummy argument is a nonpointer. Another valid implementation would be to pass a descriptor in both cases. Since the notion of referencing and dereferencing pointers is implementation dependent, the standard does not use these terms when discussing pointers and targets. The standard does state when a pointer's association status may change (pointer assignment, allocation, deallocation, nullification, and association with a dummy argument which is a pointer) and several cases where a pointer name refers to the associated target object (assignment as primary in an expression, and an I/O list). There is also an example of a pointer actual argument associated with a nonpointer dummy argument in section 12.5.2.9. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.1.2.4.3, 7.1.41, 7.5.1.5, 9.4.4.4, 12.4.1.1, & 12.5.2.9 EDIT(S): None. SUBMITTED BY: L. R. Rolison, 120-LRR-9 (120.034) HISTORY: 120-JLS-9 (120.079) ----------------------------------------------------------------------- NUMBER: 000040 TITLE: Allocation of Arrays of Pointers KEYWORDS: arrays, pointer allocation, structures DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Consider the following code fragment: TYPE DEF INTEGER I INTEGER, POINTER :: PTR END TYPE TYPE (DEF) :: STRUCT (5) ... ALLOCATE (STRUCT%PTR) Are the following quotations from the standard sufficient to declare this code fragment to be nonstandard-conforming? o The constraint immediately following R628 "Each must be a pointer or an allocatable array." o The second sentence of the fourth constraint after R613 "A to the right of a with nonzero rank must not have the POINTER attribute." ANSWER: The ALLOCATE statement in the example is not permitted by the syntax rules and constraints of the standard: R625 is or R614 is R612 is [%]... R613 is [()] Constraint: A to the right of a with nonzero rank must not have the POINTER attribute. REFERENCES: ISO/IEC 1539:1991 (E) sections 6.1.2 and 6.3.1 EDIT(S): None. SUBMITTED BY: Larry Rolison, X3J3/92-056 HISTORY: Approved as X3J3/92-069 at meeting 121 Edit approved in 92-267r at meeting 123 ----------------------------------------------------------------------- NUMBER: 000041 TITLE: Procedure with Target Dummy Argument Requires Explicit Interface KEYWORDS: dummy argument, explicit interface, TARGET attribute DEFECT TYPE: Interpretation STATUS: X3J3 consideration in progress QUESTION: If a procedure has a dummy argument that has the TARGET attribute, it must have an explicit interface (section 12.3.1.1). The TARGET attribute is defined solely for the purpose of aiding optimization (C.5.3). Why must such a procedure have an explicit interface? ANSWER: To aid optimization of the subprogram which calls the procedure and to aid in error detection. Discussion: Section 6.3.3.2 states that upon execution of a RETURN or END statement, some pointers declared or accessed in the procedure retain their association status. If a pointer is accessible to both the subprogram which references the procedure and the referenced procedure, or if the procedure is a function whose result has the POINTER attribute, such a pointer cannot become associated with an actual argument during execution of the procedure if the target actual argument becomes associated with a nontarget dummy argument. If a procedure does not have an explicit interface, a processor may assume any actual argument with the target attribute cannot become associated with such a pointer during execution of the procedure. Requiring an explicit interface for a procedure with a target dummy argument also allows the processor to diagnose association of a nontarget actual argument with the target dummy argument. REFERENCES: ISO/IEC 1539:1991 sections 6.3.3.2, 12.3.1.1, and C.5.3 EDIT(S): None. SUBMITTED BY: K. Kazumura, X3J3/92-048 (121-ADT-8) page 23 LAST SIGNIFICANT CHANGE: Approval rescinded at meeting 123 (uc) HISTORY: Posted request to f90 interp e-mail Approved as X3J3/92-070 meeting 121 Approval rescinded at meeting 123 (uc) -------------------------------------------------------------------------- NUMBER: 000042 TITLE: KIND parameter value KEYWORDS: kind parameter value, representation of constants DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: It is stated in section 5.1.1.2 that: An entity declared with type specifier REAL(KIND(0.0)) is of the same kind as one declared with the type specifier REAL. There are similar statements about INTEGER, DOUBLE PRECISION, and COMPLEX type specifiers in sections 5.1.1.1, 5.1.1.3, and 5.1.1.4. In section 5.1.1.2, for example, must the constant be exactly the characters "0.0" to cause the declared entity to be the same as the default real entity? Could the result be different if the constant were expressed, for example, as "0."? It appears that the committee chose the value 0 in these statements because it exists on every machine on which a Fortran 90 processor will be run. Further, a specific value was chosen so that machine architecture differences would be factored out. For example, KIND(10000000.) might have the same kind parameter value as default real on one machine but not on another. ANSWER: No, the constant need not be exactly "0.0". The constant "0.0" is used only as an example. Discussion: The KIND intrinsic is defined in section 13.13.51 of the standard to return a value equal to the kind type parameter of its argument; the argument may be of any intrinsic type. In section 13.5.5 it is stated that the value of the argument to this function need not be defined. It is only the kind type of the argument that is relevant. Nowhere in the standard is there a restriction that the argument to the KIND intrinsic be a constant at all, much less the specific constant 0.0. The is specified in section 5.1, R505 to be a . The definition of an is given in section 7.1.6.1, and the restrictions on the argument of the KIND intrinsic in an are detailed in item (6) of that definition. The question makes the assertion that KIND(10000000.) might not have the same kind parameter value as default real on all machines. This assertion is false. Possibly the requestor believed that a literal real constant could assume a kind parameter value based on the number of digits in the constant or some other implicit criterion. This is not allowed in Fortran 90. In section 4.3.1.2, it is explicitly stated that: A literal real constant without a kind type parameter is a default real constant if it is without an exponent part..." Similar arguments apply to the corresponding questions about INTEGER, DOUBLE PRECISION, and COMPLEX type specifiers. REFERENCES: ISO/IEC 1539:1991, sections 4.3.1.2, 5.1, 5.1.1, 7.1.6.1, 13.5.5, & 13.13.51 EDIT(S): None. SUBMITTED BY: L.R.Rolison, X3J3/92-060 HISTORY: Approved as X3J3/92-084 at meeting 121 by a vote of 19-0 Edit approved in 92-267r at meeting 123 -------------------------------------------------------------------------- NUMBER: 000043 TITLE: List-directed character input KEYWORDS: list-directed, input, character, zero length, null value DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: For list directed input of character items, how does the standard distinguish between the input of an undelimited zero-length character string and a null value? If the input is a zero-length character string, the corresponding list item must be set to blank, whereas if the input is a null value, the definition status of the corresponding list item must be left unchanged. However, there appears to be no way to distinguish these two possibilities. ANSWER: The ambiguity between undelimited zero length character values and the null value should be resolved by requiring that zero-length character values always be delimited in list-directed input. Discussion: Several other potential ambiguities with undelimited character items in list-directed input were resolved in section 10.8.1 by requiring delimiters in those cases. However, the case of a zero- length string was omitted from this list. EDIT(S): The following changes should be made to section 10.8.1, 1. Add " and" to the end of item (4), and 2. Add an additional item to the list after item (4): "(5) The character constant contains at least one character," REFERENCES: ISO/IEC 1539:1991, sections 10.8.1, 10.8.1.1 SUBMITTED BY: Richard E. Maine, X3J3/92-087 HISTORY: Approved as X3J3/92-116 at meeting 121 by a vote of 19-0 Approved in ballot 92-182 -------------------------------------------------------------------------- NUMBER: 000044 TITLE: END Statement and Fixed Form Source KEYWORDS: end statement, fixed form source, initial line DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Consider the following: 1. Section 3.3.2.4 "Fixed Form Statements", page 24, requires that no statement, except the program unit END statement, have an initial line that appears to be a program unit END statement. 2. Other statements, for example, , R1218 page 175, may consist of only the keywords "END" or "END FUNCTION". While these do not conflict, the combined requirements are not obvious and complicate the situation for users. Consider, for example, ending an for a function subprogram: 1. END !wrong, appears to be a program unit END 2. EN !END continued to 2nd line. OK & D 3. END FUNCTION !OK in main PROGRAM unit and SUBROUTINE !subprogram, wrong in FUNCTION subprogram 4. EN !OK & D FUNCTION 5. END F !OK 6. END FUNCTION A !OK in main program, OK in SUBROUTINE & BC !subprogram, OK in function if name !is not "A" ANSWER: Section 3.3.2.4 was brought forward from FORTRAN 77 without modification for new Fortran 90 constructs. The resulting usability characteristics, as seen in the examples above, are regrettable enough that a repair should be made. REFERENCES: ISO/IEC 1539:1991 (E) section 3.3.2.4 EDIT(S): In 3.3.2.4 replace the text "and no other statement in the program unit may have an initial line that appears to be a program unit END statement" with ". A statement whose initial line appears to be a program unit END statement must not be continued." SUBMITTED BY: J.C.Shepherd, X3J3/92-012, X3J3/92-013, X3J3/92-014 HISTORY: Approved as X3J3/92-088A at meeting 122 by a vote of 24-0 Edit approved in 92-267r at meeting 123 ----------------------------------------------------------------------- NUMBER: 000045 TITLE: Array Intrinsics with Arrays of Derived-type Arguments KEYWORDS: array intrinsics, derived-types, operations, interface blocks DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: The intrinsic functions ALLOCATED, ASSOCIATED, LBOUND, UBOUND, PRESENT, SHAPE, SIZE, MERGE, PACK, SPREAD, UNPACK, CSHIFT, EOSHIFT, TRANSPOSE, RESHAPE, and TRANSFER are documented as accepting arrays of any type. Does this include arrays of derived-type, and if so, does this conflict with section 4.4.5 which states: Any operation on derived-type entities or nonintrinsic assignment for derived-type entities must be defined explicitly by a function or subroutine and a procedure interface block. ANSWER: The intrinsics in question can accept arguments which are arrays of derived-types. This does not conflict with section 4.4.5. Discussion: The term "operation" in section 4.4.5 refers to user defined unary and binary operations in expressions and nonintrinsic assignments. Such operators are defined by means of interface blocks which define operators and nonintrinsic assignment. Using an object as an actual argument in a procedure reference is not considered an operation on that object in this sense. REFERENCES: ISO/IEC 1539:1991 section 4.4.5 and 13.13 X3J3/92-051 pages 13-14 EDIT(S): None. SUBMITTED BY: H.Funaki, X3J3/92-051 (121-ADT-11) pp13-14 HISTORY: Posted request to f90 interp e-mail Approved as X3J3/92-092A meeting 121 by a vote of 19-0 Edit approved in 92-267r at meeting 123 ----------------------------------------------------------------------- NUMBER: 000046 TITLE: RESULT clause for RECURSIVE functions KEYWORDS: result clause, recursive functions DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: 1. Does RECURSIVE require RESULT? 2. Assuming (1), is a permitted on the function name when RECURSIVE is present? ANSWER: The RESULT clause is not required for all RECURSIVE functions; it is required for those that are directly recursive. That is, the RESULT clause is necessary to make the function visible in its own body so that direct recursion can take place. It should be noted that the prohibition against typing the function name when a result variable name is specified was not intended to prohibit putting the function type into the header. In other words: FUNCTION F() RESULT (FVAR) INTEGER FVAR and INTEGER FUNCTION F() RESULT (FVAR) are both allowed. The case prohibited is: FUNCTION F() RESULT (FVAR) INTEGER F It is possible for both a and RECURSIVE to appear in a single function header. REFERENCES: ISO/IEC 1539:1991 (E) section 12.5.2.2 EDIT(S): None. SUBMITTED BY: L.Meissner, X3J3/92-045 (121-ADT-5) p17. HISTORY: For discussion see X3J3/92-45 (121-ADT-5) pp 18, 26-27 Approved as X3J3/92-101 at meeting 121 by a vote of 20-0 Edit approved in 92-267r at meeting 123 ----------------------------------------------------------------------- NUMBER: 000047 TITLE: Automatic data object in initialization expressions KEYWORDS: automatic data object, initialization expressions DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Can an automatic data object be used as the argument to the LEN function in the initialization expression of a PARAMETER statement or an item given the PARAMETER attribute? ANSWER: It was the intent of the committee to include objects with non constant lengths in the restrictions on the LEN function in section 7.1.6.1 (pages 77 and 78). REFERENCES: ISO/IEC 1539:1991 (E) section 7.1.6.1 EDIT(S): 1. Section 7.1.6.1, page 77, item (6) change "not assumed or" to "not assumed, are not defined by an expression that is not a constant expression, and are not" 2. Section 7.1.6.1, page 78, item (6) change "not assumed or" to "not assumed, are not defined by an expression that is not a constant expression, and are not" SUBMITTED BY: 120.042 HISTORY: For discussion see 120.073A and X3J3/92-036 (121-JKR-4) Approved as X3J3/92-107 at meeting 121 by a vote of 20-0 Edit approved in 92-267r at meeting 123 -------------------------------------------------------------------------- NUMBER: 000048 TITLE: Pointer-valued statement functions KEYWORDS: statement function, pointer DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Can a statement function be pointer-valued? There appears to be nothing in section 12.5.4 to prohibit this. ANSWER: No, a statement function cannot be pointer-valued. Discussion: From section 12.3.1: The interface of a statement function is always implicit. From section 12.3.1.1: A procedure must have an explicit interface if... (2) The procedure has: (e) A result that is a pointer (functions only) Therefore, a statement function cannot have a result that is a pointer. REFERENCES: ISO/IEC 1539:1991 sections 12.3.1, 12.3.1.1, 12.5.4 EDIT(S): None. SUBMITTED BY: L.Meissner, X3J3/92-45 (121-ADT-5) p37 HISTORY: Approved as X3J3/92-108 at meeting 121 by a vote of 19-0 Edit approved in 92-267r at meeting 123 -------------------------------------------------------------------------- NUMBER: 000049 TITLE: Characteristics of Function Results KEYWORDS: characteristics, function result, ENTRY, exact dependence, partially associated DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Given a character function with an ENTRY statement, both results must have the same characteristics or be scalars without the POINTER attribute and have identical length. Therefore: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN,ENT ... ENTRY ENT(M,N) ... END FUNCTION is standard conforming. Question 1: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN CHARACTER (LEN=M+N)::ENT ... ENTRY ENT(M,N) ... END FUNCTION Is the code above standard conforming? Question 2: FUNCTION FUN(M,N) CHARACTER (LEN=M+N)::FUN CHARACTER (LEN=N+M)::ENT ... ENTRY ENT(M,N) ... END Is the code above standard conforming? Question 3: FUNCTION FUN(M) CHARACTER (LEN=M+M)::FUN CHARACTER (LEN=M*2)::ENT ... ENTRY ENT(M) ... END Is the code above standard conforming? Question 4: What is the meaning of the phrase "the exact dependence on the entities" in section 12.2.2? ANSWER: Answer 1. Yes Answer 2. Yes Answer 3. Yes Answer 4. The phrase "the exact dependence on the entities" in section 12.2.2 refers to run-time values, which may or may not be known at compile- time. The requirement "must...be of type default character with identical length" is a requirement for a standard-conforming program. Since it is not a constraint, a processor is not required to detect a violation of this requirement even if the lengths are known at compile- time, though it may do so. Discussion: The examples in the first three questions are examples of totally associated variables, and not partially associated, so their lengths must be identical at run-time. Therefore, examples in questions 1-3 are standard conforming. During consideration of the fourth question, it became apparent that the text in the standard on partial association (14.6.3.3) needs correction. Given the definition of "partially associated" in section 14.6.3.3: "Two scalar entities are partially associated if they are associated without being totally associated." The last sentence before the first example in 14.6.3.3 [168:41] For character entities, partial association may occur only through argument association, or the use of COMMON, EQUIVALENCE, or ENTRY statements. is incorrect. There is no way that partial association for character entities may occur through the use of an ENTRY statement. REFERENCES: ISO/IEC 1539:1991 (E) section 12.2.2 & 14.6.3.3 EDIT(S):In section 14.6.3.3 change the sentence (last two lines of page 248) from "For character entities, partial association may occur only through COMMON, EQUIVALENCE, or ENTRY statements" to "For character entities, partial association may occur only through COMMON or EQUIVALENCE statements". SUBMITTED BY: Y.Yoshida, X3J3/92-051 (121-ADT-11) pp11-13 LAST SIGNIFICANT CHANGE: 1992 11 12 HISTORY: Approved as X3J3/92-109A at meeting 121 by a vote of 19-0 resubmitted in 92-313 in response to ballot comments and approved by unanimous consent at meeting 123. -------------------------------------------------------------------------- NUMBER: 000050 TITLE: Repeat counts on edit descriptors KEYWORDS: edit descriptor, repeat count DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Is the repeat specification part of the edit descriptor? Discussion: In section 10.1.1 the second constraint states that the comma separating the in a is optional between certain combinations of edit descriptors. In section 10.2 a format-item is defined as, amongst other things, "[r]" and in 10.2.1 an edit-descriptor can be a data- edit-desc. However, does not contain the repeat count. This implies that: 100 FORMAT(1PE20.10) !is legal 200 FORMAT(1P3E20.10) !is not legal 300 FORMAT(1P,3E20.10) !is legal ANSWER: The repeat count is not part of any edit descriptor except the "[r]/" edit descriptor. The comments in the examples are correct. REFERENCES: ISO/IEC 1539:1991, sections 10.1.1, 10.2, & 10.2.1 EDIT(S): None. SUBMITTED BY: A.D.Tait, X3J3/92-041 (121-ADT-1) HISTORY: X3J3/92-041, X3J3/92-042 This problem appears to stem from an incompatibility between FORTRAN 66 and FORTRAN 77. In FORTRAN 66 a FORMAT statement is of the form: FORMAT(list) where the list consists of a series of field descriptors separated by field separators and optionally preceded and succeeded by slashes. The field descriptors for real or double precision values consisted of the now familiar Dw.d, Ew.d, Fw.d, and Gw.d edit descriptors (a term introduced in FORTRAN 77) preceded by an optional scale factor and repeat count. For example, in FORTRAN 66 a valid field descriptor is 1P3E17.10, where 1P is the scale factor, 3 the repeat count for a field containing 10 digits in the fractional part of the number and having a E exponent. In FORTRAN 77 the scale factor is an edit descriptor and thus is a list element in the format specification. While FORTRAN 77 specifies places where the commas separating list elements in a format specification are optional, it fails to make a comma between the scale factor and an immediately succeeding repeated D, E, F, or G edit descriptor optional. This situation has been carried over to Fortran 90. Thus: 100 FORMAT(1PE20.10) !is legal in F66, F77, and F90 200 FORMAT(1P3E20.10) !is legal in F66, and illegal in F77 & F90 300 FORMAT(1P,3E20.10) !is illegal in F66, and legal in F77 & F90 Edit approved in 92-267r at meeting 123. -------------------------------------------------------------------------- NUMBER: 000051 TITLE: On Unambiguous generic procedure references KEYWORDS: generic procedure DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Should the rules in 14.1.2.3 include a rule that uses the fact that a dummy argument is either a subroutine or a function to disambiguate a generic procedure reference? For example, such a rule could be in section 14.1.2.3, in the sentence that is preceded by "(1)"U, after "with a different type" adding "present as a subroutine instead of a function". ANSWER: No. The intent of the committee was to keep the rules as simple as possible in order that they would be easy to understand and to use. It is not always possible for the processor to tell whether an actual argument that is a procedure is a subroutine or an implicitly typed function. REFERENCES: ISO/IEC 1539:1991 (E) section 14.1.2.3 EDIT(S): None. SUBMITTED BY: John Reid, SC22/WG5 N786A HISTORY: X3J3/92-017 at meeting 121 - RFI: generic interfaces and dummy procedure arguments Approved as X3J3/92-151 at meeting 122 by a vote of 25-0 -------------------------------------------------------------------------- NUMBER: 000052 TITLE: Expressions in Statement Function Definitions KEYWORDS: statement functions, array, variable, intrinsic operator, expression DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Section 12.5.4 appears to prohibit whole array names appearing as actual arguments to functions within the of a statement function. The first constraint states: The may be composed only of constants (literal and named), references to scalar variables and array elements, references to functions and function dummy procedures, and intrinsic operators. A defined operator may be an extended intrinsic operator, as well as a defined unary or binary operator. Question 1: Is the legal FORTRAN 77 program fragment, EXTERNAL FCN REAL A(2) STFN(X) = FCN(A) + X where FCN is some function and STFN is a statement function, a legal Fortran 90 program fragment? Question 2: Is it intended that a defined operator which is an extended intrinsic operator be allowed in a statement function definition but other defined operators not be allowed? ANSWER: The intent is that the program fragment in question one should be a valid Fortran 90 program fragment, and that no defined operators be allowed in a statement function definition. The standard is in error. The edits below should be applied to correct the standard. Discussion: The intent of the standard was to retain the FORTRAN 77 definition of statement functions without extending it to include defined operators or array expressions. In FORTRAN 77, "expression" and "variable" referred only to scalar expressions and variables; there were no defined operators. In Fortran 90 these terms also refer to array expressions and arrays. The Fortran 90 definition of statement functions was intended to prohibit array expressions but overlooked the use of an array name as an actual argument to a function in the definition of a statement function. REFERENCES: ISO/IEC 1539:1991 section 12.5.4 EDIT(S): Section 12.5.4 1. First constraint, first sentence change "references to scalar variables and array elements" to "references to variables" change "intrinsic operators" to "intrinsic operations" after first sentence add If contains a reference to a function or a function dummy procedure the reference must not require an explicit interface, the function must not require an explicit interface or be a transformational intrinsic, and the result must be scalar. If an argument to a function or a function dummy procedure is array valued, it must be an array name." 2. Second constraint, third sentence change "scalar variable, array element" to "variable" 3. Fifth constraint, first sentence delete second word ("scalar") SUBMITTED BY: A. D. Tait X3J3/92-064 item # 13 points to B. Smith e-mail in X3J3/92-045 pp. 50-52 HISTORY: Approved as X3J3/92-153A at meeting 122 by a vote of 17-2 -------------------------------------------------------------------------- NUMBER: 000053 TITLE: Optional Intrinsic Function Arguments KEYWORDS: intrinsic functions, optional arguments DEFECT TYPE: Amendment STATUS: X3J3 draft response 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? 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. REFERENCES: ISO/IEC 1539:1991 (E) 12.5.2.8, 13.13.20, 13.13.46, 13.13.50, 13.13.52, 13.13.63, 13.13.68, 13.13.91, 13.13.111, 13.13.113. EDIT(S): 1. Add the following point to the numbered list in section 12.5.2.8: (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" SUBMITTED BY: response to X3J3/92-058 (121-LRR-5) HISTORY: Submitted as question in 92-058, draft response prepared in X3J3/92-094, and in N815A of the WG5 Victoria meeting based on John Reid's paper, N786A. X3J3/92-156r approved at meeting 122 -------------------------------------------------------------------------- NUMBER: 000054 TITLE: Resolving Generic Procedure References KEYWORDS: generic, interface, intrinsic DEFECT TYPE: Interpretation Status: X3J3 draft response QUESTION: Consider the following code fragment: PROGRAM HOST DIMENSION ABS(10) ... CONTAINS SUBROUTINE SUB() INTERFACE ABS FUNCTION IA1(I) INTEGER IA1, I END FUNCTION END INTERFACE R = ABS(1.5) Do the rules for resolving references to names established to be generic (14.1.2.4.1) imply that R will be assigned the value 1.5 as the result of invoking the intrinsic ABS? ANSWER: Yes. Discussion: ABS is established to be generic in the scope of subroutine SUB (14.1.2.4 item 1(a)). The rules in section 14.1.2.4.1 can be used to resolve the procedure reference. Rule (1) in 14.1.2.4.1 does not apply, as the reference is not consistent with any specific interface in the interface block with the name ABS. Rule (2) does not apply as ABS does not appear in an INTRINSIC statement. Rule (3) does not apply as ABS is not established to be generic in the host scope. Therefore, rule (4) is applied and the reference is resolved to the generic intrinsic procedure ABS. REFERENCES: ISO/IEC 1539:1991(E) Sections 14.1.2.4 and 14.1.2.4.1 SUBMITTED BY: J.C. Shepherd HISTORY: One of the questions raised in X3J3/92-048 pg 29-30, 34-40, 51, 52 and X3J3/92-052 pg 1-3. Initially drafted as X3J3/92-119 X3J3/92-157 approved at meeting 122 -------------------------------------------------------------------------- NUMBER: 000055 TITLE: Characteristics of character function results KEYWORDS: character function, function result DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: In section 12.5.2.5 the second paragraph after the constraints contains the text: "Otherwise, they are storage associated and must all be scalars without the POINTER attribute and all be of type default character with identical length". Is some of this text redundant? ANSWER: Yes. Discussion: The phrase referring to "identical length" was meant to include the FORTRAN 77 character storage association case. FORTRAN 77 requires either that they all be of assumed length or all be of the same constant length; both are included as characteristics that agree in section 12.5.2.5 in the second paragraph after the constraints that starts with "If the ENTRY". The phrase is redundant and is causing confusion. REFERENCES: ISO/IEC 1539:1991 (E) section 12.5.2.5. EDIT(S): In Section 12.5.2.5 in the sentence that starts: "Otherwise, they ... " delete: "all be scalars ... length or". SUBMITTED BY: J.K.Reid in N786A at the WG5 Victoria Meeting, July 1992. HISTORY: Drafted at the WG5 Victoria Meeting July, 1992 and submitted to X3J3 at meeting 122 X3J3/92-158 approved at meeting 122 -------------------------------------------------------------------------- NUMBER: 000056 TITLE: TRANSFER intrinsic function description KEYWORDS: Intrinsic functions, examples DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Should the text of Case (iii) under Examples in the TRANSFER intrinsic function be corrected so the example reads: Case (iii): TRANSFER((/1.1,2.2,3.3/),(/ (0.0,0.0) /),1) is a complex rank-one array of length one whose sole element has the value (1.1,2.2)." ANSWER: No. Discussion: The current format of the example, 1.1+2.2i, is valid mathematical notation for complex type. REFERENCES: ISO/IEC 1539:1991 (E) Section 13.13.108. EDIT(S): None. SUBMITTED BY: Larry Rolison in X3J3/92-059 (121-LRR-6) LAST SIGNIFICANT CHANGE: 1992 11 11, opposite response HISTORY: Submitted as a request in X3J3/92-059 Draft response first prepared in X3J3/92-091 Subsequent draft in X3J3/92-159 - rejected at meetings 121 and 122 Revised response proposed in X3J3/92-294 - Approved by unanimous consent at meeting 123 -------------------------------------------------------------------------- NUMBER: 000057 TITLE: Prohibition against multiple explicit specific interfaces KEYWORDS: specific interfaces, interface body, interface block DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: What is the meaning and/or intent of the following sentence in 12.3.2.1? A procedure must not have more than one explicit specific interface in a given scoping unit." Multiple SPECIFIC interfaces can not be produced by the existence of interface blocks because the definition of an interface body states that it only specifies an EXPLICIT interface, not a SPECIFIC interface. If the statement in 12.3.2.1: "An external or module subprogram definition specifies a specific interface for the procedures defined in that subprogram", only external or module subprograms have specific interfaces and the specific interfaces are only specified by the text of the subprogram itself. Could an example of code be provided that is prohibited by the statement "a procedure must not have more than one explicit specific interface in a given scoping unit" in 12.3.2.1 and that would not be prohibited by some other provision of ISO/IEC 1539:1991? ANSWER: The statement in the question that "Multiple SPECIFIC interfaces can not be produced by the existence of interface blocks" is incorrect. An example follows. Discussion: The paragraph following the constraints, in 12.3.2.1 is concerned with "specific interfaces" and it was intended to be understood from the context in that discussion that the interface specified by an interface body should be both specific and explicit. See also 14.1.2.4, (2), (a) which shows that it was intended that an interface body define a specific interface. The intention was to disallow the same information being provided twice,as for other specifications. An edit is supplied to make this clearer. An example which illustrates what is prohibited follows: Example: MODULE MOD INTERFACE SUBROUTINE SUB(I,J) INTEGER I,J END SUBROUTINE SUBROUTINE SUB(M,N) ! duplication of SUB is illegal INTEGER M,N END SUBROUTINE END INTERFACE END MODULE REFERENCES: ISO/IEC 1539:1991 (E) section 12.3.2. EDIT(S): Section 12.3.2.1, the sentence that begins "An interface body..." change "explicit interface" to "explicit specific interface". SUBMITTED BY: L. Rolison LAST SIGNIFICANT CHANGE: 1992 11 12 HISTORY: 120.035, 120.090 Approved as X3J3/92-162A at meeting 122 by unanimous consent Revised following letter ballot at meeting 123 in 92-314 to correct transcription errors in the recording of what was contained in 92-162A. -------------------------------------------------------------------------- NUMBER: 000058 TITLE: Ambiguous use of "keyword" KEYWORDS: keyword, argument keyword DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Is the use of "keyword" in 12.4.1 page 172 1st paragraph consistent with the definition of "keyword" in 3.2.1, page 19? Is the definition of keyword in 3.2.1 consistent with the two definitions of keyword in 2.5.2 page 16? In 13.10 page 188 is "keyword" the correct term (or should it be "argument keyword")? ANSWER: For each question, the answer is "NO". There are two different definitions of "keyword", 2.5.2 page 16 and 3.2.1 page 19. Neither definition is complete. The edits below combine these two definitions into one and consistently use "argument keyword" where appropriate. REFERENCES: ISO/IEC 1539:1991 (E) sections 2.5.2, 3.2.1, 12.4.1,& 13.10 EDIT(S): 1. Page 5, section 1.5.3, (3) [5:9] delete "keyword actual arguments and" rationale: these are not specifiers and -spec is not used with them. 2. Page 16, section 2.5.2, 1st pp, 1st occurrence [16:3] change "statement keyword" --------- ------- to "statement keyword (often abbreviated to keyword)" --------- ------- ------- rationale: define "keyword", in a style similar to "object" in 2.4.3.1. 3. Page 16, section 2.5.2, 1st pp, end of [16:5] add "Keywords appear as upper-case words in the syntax rules in Sections 4 through 12". 4. Page 16, section 2.5.2, 2nd pp 1st sentence [16:6] change "name." to "name (see 12.4.1)." 5. Page 19, section 3.2 [19:35] change "keywords" to "statement keywords (2.5.2)" 6. Page 19, section 3.2.1 [19:37-38] delete rationale: 2.5.2 is now the complete definition. 7. Page 160, section 11.3.3.5, 1st pp, 3rd line [160:29] change "keywords" to "argument keywords" 8. Page 168, the pp following the line "END INTERFACE", 2nd sentence [168:24] replace with "Invocations of these procedures may use argument keywords; for example:" rationale: "keyword calls" is not defined. In general invocations can use both positional and argument keywords. 9. Page 172, 1st paragraph following constraints, 3 occurrences [172:13,16,17] change "a keyword" to "an argument keyword", two occurrences, and change "the keyword" to "the argument keyword" 10. Section 13.3, first sentence [183:37], set "positional arguments" and "keyword arguments" in regular font 11. Page 183, section 13.3, 1st pp, 3rd line, 2 occurrences [183:38] change "the keyword" to "the argument keyword" and change "A keyword" to "An argument keyword" 12. Page 188, section 13.10, 1st pp, 1st two lines, 2 occurrences [188:12,13] change "keyword" to "argument keyword" and change "keywords" to "argument keywords" 13. Page 363, entry for "argument keywords 183" [363:37] delete rationale: odd to index both singular and plural. "Keyword", and "statement keyword" are indexed to p16, as is the remaining entry for "argument keyword". 14. Annex F, delete entry for "positional arguments" [368:13] SUBMITTED BY: GEN HISTORY: WG5/N808, Question 2. Approved as X3J3/92-164A at meeting 122 by a vote of 17-4 -------------------------------------------------------------------------- NUMBER: 000059 TITLE: SEQUENCE derived type and component bounds KEYWORDS: SEQUENCE, derived type DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Given two objects of SEQUENCE derived type, can the two objects be of the same derived type if the only difference between the two SEQUENCE derived type definitions is the value of the low bound and high bound for one dimension of one of the components (assuming the extent of the dimension of the array component matches the extent given in the other; and there are no structure components that have PRIVATE accessibility)? The description of when two objects of SEQUENCE derived type have the same type includes the words (2nd paragraph of 4.4.2 "Determination of derived types") "have structure components that do not have PRIVATE accessibility and agree in order, name, and attributes". This text seems to imply that if the derived type includes an then the individual low bounds and high bounds have to be the same. An example that corresponds to the question above: SUBROUTINE S() TYPE T SEQUENCE INTEGER A(1:10) END TYPE TYPE (T) X CALL S2(X) ... SUBROUTINE S2(Y) TYPE T SEQUENCE INTEGER A(2:11) END TYPE TYPE (T) Y ... Do X and Y have the same type? ANSWER: No. Discussion: The attributes that a data object may have are enumerated in section 5.1.2. Included in these is the DIMENSION attribute (section 5.1.2.4). In reference to the explicit shape arrays in the example above, in order for the attributes to agree, the values of the corresponding lower bounds and the corresponding upper bounds in must be equal. REFERENCES: ISO/IEC 1539:1991(E) 5.1.2 EDIT(S): None. SUBMITTED BY: Janice C. Shepherd X3J3/92-129 HISTORY: X3J3/92-129 Approved as X3J3/92-165A at meeting 122 by a vote of 19-2 Approved in ballot 92-182 -------------------------------------------------------------------------- NUMBER: 000060 TITLE: Statement function argument references KEYWORDS: statement function arguments DEFECT TYPE: Interpretation STATUS: X3J3 draft response QUESTION: Consider the following program: PROGRAM TEST INTEGER AR EXTERNAL AR REAL A(2), FUN, X, Y DATA A/2*5./ FUN(X) = X+X+X Y=FUN(A(AR(5))) END INTEGER FUNCTION AR(I) INTEGER I AR = 1 PRINT *, I RETURN END When the statement function is referenced, how many times is the function AR called? Or, to put it another way, how many times is the PRINT statement in function AR executed during the statement function reference? ANSWER: In the program above, the function AR is called once unless the value of the function "can be determined otherwise" than by evaluating the function. Therefore, the PRINT statement in function AR is executed at most once. Discussion: When the statement function is referenced, the actual arguments are evaluated and the resulting values are associated with the corresponding dummy arguments. The statement function FUN has only one actual argument which contains only one reference to the external function AR. Therefore, the function AR is called once as part of the evaluation of the actual argument. The value resulting from this evaluation is associated with the single dummy argument of the statement function FUN. Though the print statement may be executed once, note that 7.1.7.1 gives license to the processor to not execute the print statement at all. Thus the statement in the answer is "the PRINT statement in function AR is executed at most once". REFERENCES: ISO/IEC 1539:1991 (E) sections 12.5.4, the fourth paragraph after the last constraint. EDIT(S): None. SUBMITTED BY: Linda J. O'Gara LAST SIGNIFICANT CHANGE: 1992 11 13 HISTORY: 121-LJO-3, 121-ADT-11 pages 14-17 Approved as X3J3/92-168 at meeting 122 by a vote of 17-0 Revised after letter ballot at meeting 123, in paper 92-315. Revision approved by unanimous consent in meeting 123. --------------------------------------------------------------------------