PC File: 95-006a1.100 Archive: 95-006r1.A100 -------------------------------------------------------------------------------- NUMBER: 000100 TITLE: ASSOCIATED intrinsic and zero-sized objects KEYWORDS: ASSOCIATED intrinsic, zero-sized objects, target, pointer DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: What is the behavior of the ASSOCIATED intrinsic function for zero-sized arguments? Question 1: Can the single argument form of the ASSOCIATED intrinsic return true as its result if the argument's target is zero sized? Question 2: Can the two-argument form of the ASSOCIATED intrinsic return true when both arguments are zero sized? The following need answers only if the answer to question 2 is yes. Question 2a: If the arguments to ASSOCIATED are zero sized but of rank greater than one, must the extents of each dimension be the same for ASSOCIATED to return true? For example, what is printed by the following program? PROGRAM HUH REAL, DIMENSION(:,:), POINTER :: P1, P2 REAL, DIMENSION(10, 10), TARGET :: A P1 => A(10:9:1, :) P2 => A(:, 10:9:1) PRINT *, ASSOCIATED (P1, P2) END Question 2b: In the following example, rank, shape, type, kind type parameters, and extent of dimensions of the zero-sized arguments to ASSOCIATED match, but the second argument is not the same as the right hand side of the previous pointer assignment statement. What is the output of this program? (Does a notion of "base address" come to play for zero-sized objects as it does for nonzero-sized objects?) PROGRAM HMMM REAL, DIMENSION(:,:), POINTER :: P1 REAL, DIMENSION(10, 10), TARGET :: A P1 => A(:, 2:1:1) PRINT *, ASSOCIATED (P1, A(:, 3:2:1)) END ANSWERS: Answer 1: The one-argument form of ASSOCIATED returns a result of true if the pointer actual argument is currently associated with a target, even if the target is zero sized. Answer 2: No; if either argument is zero sized the result is false. The following edits clarify the intent. Answer 2a: The result is false because P1 and P2 each are zero sized. Answer 2b: The result is false because the arrays are of zero size. Discussion: The reasons for having the ASSOCIATED function return false for zero-sized arrays is based on an analogy with sharing storage and how assignment works. In normal English we understand the concept of "totally associated" and "partially associated". If two things are totally associated then doing something to one of them does the exact same thing to the other. If two things are partially associated then doing something to one of them does something to the other. Section 14.6.3.3 hints at this by discussing "totally associated" in terms of "the same storage sequence". After executing assignment statements like I = values J = different_values we would call I and J associated if it were no longer true that I == values. Zero-sized arrays are the end case where doing "something" to them is equivalent to doing nothing to them. And in the example above we would still have I == values after the assignment if both I and J were zero-sized but would otherwise appear to be associated. We could also conclude that after the pair of assignment statements above executed we would have I == different_values if I and J were zero sized, since the comparison operators return true for zero-sized objects. However, on balance it seems better to view the comparison with the initial conditions, not the potential changed conditions. As a practical matter sensible use of the ASSOCIATED function with zero-sized arrays will usually require user special casing of the results. EDITS: 1. Section 13.13.13 Case (ii) [198:37], replace by "If TARGET is present and is a target, the result is true if TARGET does not have size zero and POINTER is currently associated with TARGET. Otherwise, the result is false." 2. Section 13.13.13 Case (iii) [199:1], replace by "If TARGET is present and is a pointer, the result is true if both POINTER and TARGET are currently associated with the same nonzero-sized target. Otherwise the result is false." SUBMITTED BY: Jon Steidel - X3J3/92-240 HISTORY: ui 114 (jw note) 92-240 m123 Submitted 93-035 m124 response, adopted by unanimous consent 93-111 m125 ballot, return to subgroup based on Hirchert, Maine comments. Also see Ellis comment for 000108 93-138r m125 revised response adopted 11-8. 93-255r1 m127 ballot passed 21-3 94-160 m129 WG5 ballot, failed 94-253r3 m130 revised response, approved u.c. 94-306 m131 X3J3 ballot, approved 15-4 -------------------------------------------------------------------------------- NUMBER: 000101 TITLE: Specification statements KEYWORDS: specification statements DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: In many cases references to "specification statements" must also include reference to type declaration and other statements. Examples are: In 11.3.3.1 page 159 "A common block and all its associated specification statements" should be changed to: "............................... and type-declaration " In 12.3.2 page 167 "... and by specification statements for the dummy arguments ..." should be changed to "........................ and type-declaration ....." In 12.5.2.2 page 175, in the first constraint "... any specification statement ..." should be changed to "... any specification or type-declaration statement ..." ANSWER: The definition of specification statement has been corrected so that the suggested (but incomplete) edits are not required. EDITS: 1. Section 2.1, R207 [8:8] change 'specification-stmt' to 'declaration-stmt' 2. Section 2.1, R214 [8:29] change 'specification-stmt' to 'declaration-stmt' 3. Section 2.3.1, following 2nd paragraph [11:13+] insert new paragraph: Specification statements are all the statements that can appear in the , except for the ENTRY and FORMAT statements. note to editor: "Specification statements", above, should be in bold. 4. Figure 2.1, [11:30] change 'Specification' to 'Declaration' 5. In note to Figure 2.1, [12:31] change 'Specification' to 'Declaration' SUBMITTED BY: Dick Weaver HISTORY: 92-244r2 m123 first submitted 92-325 m123 initial response 93-145 m125 revised questions and edits, approved 14-1 93-255r1 m127 ballot failed 16-7 94-036 m128 delete edits to section D -------------------------------------------------------------------------------- NUMBER: 000121 TITLE: ";" As a Statement Separator KEYWORDS: source form - statement separator, ";" DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Are the following cases legal? (1) C = A ; + B (2) F = ; & G (3) ; P = Q The phrase "partial statements" used in sections 3.3.1.2 and 3.3.2.2 would suggest that they are legal code fragments. It was likely the intention that the semicolon be permitted after a complete statement and (possibly) before the start of a subsequent statement. ANSWER: None of the cases are conforming. DISCUSSION: The phrase "partial statements" used in 3.3.1.2 and 3.3.2.2 was intended to describe the strictly lexical entity resulting when a line is continued in mid-statement. A statement interrupted by continuation, and the associated portion on the subsequent line, are two partial statements. Thus it was intended that breaking a statement into two partial statements be accomplished by continuation only, and not also by the ";" separator. Edits are provided to avoid the use of the phrase "partial statements" while making more concise the intention of the standard committee. With these edits, the following are conforming examples, and cases (1), (2) and (3) are nonconforming. F = & G ; P = & ! conforming Q F = & G ; P = Q ! conforming F = G ; P = & ! conforming Q EDITS: 1. Section 3.3.1.2 [22:44-45], change the first sentence to read as follows: 'The character ";" terminates a statement, except when the ";" appears in a character context or in a comment. This optional termination allows another statement to begin following the ";" on the same line. A ";" must not appear as the first nonblank character on a line.' 2. Section 3.3.1.2 [23:1-2], eliminate the last sentence of this section (it becomes redundant with edit 1). 3. Section 3.3.2.2 [23:36-37], change the first sentence to read as follows: 'The character ";" terminates a statement, except when the ";" appears in a character context, in a comment or in character position 6. This optional termination allows another statement to begin following the ";" on the same line. A ";" must not appear as the first nonblank character on a line, except in character position 6.' 4. Section 3.3.2.2 [23:39-40], eliminate the last sentence of this section (it becomes redundant with edit 3). SUBMITTED BY: Paul St. Pierre, 119-PSP-1 HISTORY: 119-PSP-1 (initial submission) ui 94 (jw note) 92-284 m123 considered 94-072r1 m128 new response approved uc 94-116 m129 X3J3 ballot failed 13-10 94-243r1 m130 Revised 3rd edit and revised question to be closer to original question. Approved u.c. 94-306 m131 X3J3 ballot approved 19-0 -------------------------------------------------------------------------------- NUMBER: 000127 TITLE: Is a module a global entity? KEYWORDS: module, global entity, local entity DEFECT TYPE: Interpretation STATUS: Hold - Returned by WG5 for X3J3 reconsideration QUESTION: Consider the following program fragment: MODULE ABC INTEGER G END MODULE PROGRAM MAIN USE ABC ! Contains name ABC REAL ABC ! Contains name ABC END PROGRAM Question 1: Is a module a global entity? Question 2: May a local entity of class(1) in a scoping unit have the same name as a module accessed by that scoping unit? Question 3: May a module be accessed in a scoping unit that also accesses a local name that has the same name as the module? Specifically, in the example below can subroutine SUB reference the variable ABC? MODULE ABC INTEGER G END MODULE PROGRAM MAIN REAL ABC ! Contains name ABC ... CONTAINS SUBROUTINE SUB USE ABC ! Contains name ABC ... END SUBROUTINE END PROGRAM ANSWER: Answer 1: Yes, a module is a global entity. Answer 2: No, a local entity of class(1) in a scoping unit may not have the same name as a module accessed by that scoping unit. Answer 3: No, a module can not be referenced in a USE statement in a scoping unit that also accesses a local name that has the same name as the module. Variable ABC is not accessible by that name in the subroutine SUB. Discussion: The first sentence of Section 11 indicates that a module is a program unit. Section 14.1.1 defines global entities. The definition includes module names because the definition lists program units. Section 14.1.2 states that a name that identifies a global entity must not be used to identify a local entity of class(1). Section 11.3 [157:24-26] states: The module name is global to the executable program, and must not be the same as the name of any other program unit, external procedure, or common block in the executable program, nor be the same as any local name in the module. This would mean that the following: MODULE ABC REAL ABC END MODULE is NOT standard conforming. Section 14.1.2 [241:29-31] states: Except for a common block name (14.1.2.1) or an external function name (14.1.2.2), a name that identifies a global entity in a scoping unit must not be used to identify a local entity of class (1) in that scoping unit. The original description of host association in 12.1.2.2.1 inadvertently failed to account for module names. A correction to that section has rectified the omission (defect item 90). 12.1.2.2.1 now clearly states that the appearance of a name as the in a will prevent access by host association to an entity of the same name in the host scoping unit. EDIT: None SUBMITTED BY: Larry Rolison in x3j3/93-037 at m124. HISTORY: 93-037 m124 Submitted 93-097 m124 Draft response failed 93-148 m125 Revised response, withdrawn 93-235 m126 Revised response based on edit in item 82. approved uc 93-255r1 m127 ballot passed 24-0 HOLD per 82 93-327 m127 edits to 82, 90, 99, 127 approved uc 94-034 m128 X3J3 ballot passed 27-0 94-160 m129 WG5 ballot failed HOLD per 90 -------------------------------------------------------------------------------- NUMBER: 000129 TITLE: Array constructors in initialization expressions KEYWORDS: array constructor, expression - initialization, implied-DO variable DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: It was likely the intent of the standard to allow the program fragment INTEGER ARRAY(3) PARAMETER ( ARRAY = (/ (ABS(I), I=-3,-1) /) ) However, according to the text in the second list in 7.1.6.1 "(/ (ABS(I), I=-3,-1) /)" is not an initialization expression. The array constructor "(/ ABS(-3), ABS(-2), ABS(-1) /)" qualifies as an initialization expression since item (2) in the list indicates that an array constructor is an initialization expression if each element is an initialization expression, and (4) includes "An elemental intrinsic function reference of type integer or character where each argument is an initialization expression of type integer or character" The problem with the "ABS(I)" in PARAMETER ( ARRAY = (/ (ABS(I), I=-3,- 1) /) ) is that "ABS(I)" is not defined as an initialization expression. It does not qualify under (4) as "I" is not an initialization expression and it does not qualify under (2) as the primary ABS(I) is neither an initialization expression nor an implied-DO variable. Is the program fragment standard conforming? ANSWER: Yes, the fragment was intended to be standard conforming. This is an error in the standard that is corrected by the edits below. Similar corrective edits are included for the definitions of constant and restricted expressions. EDITS: 1. In section 7.1.6.1, in the first list, in item 2 [77:20], change: "either constant expressions or implied-DO variables," to: "constant expressions," 2. In section 7.1.6.1, in the first list, in item 6 [77:28], delete the last "or" 3. In section 7.1.6.1, in the first list, add as item 7 and renumber the rest [77:28+]: "(7) An implied-DO variable within an array constructor where the bounds and strides of the corresponding implied-DO are constant expressions, or" 4. In section 7.1.6.1, in the second list, in item 2 [77:39], change: "either initialization expressions or implied-DO variables," to: "initialization expressions," 5. In section 7.1.6.1, in the second list, in item 6 [78:10], delete the last "or" 6. In section 7.1.6.1, in the second list, add as item 7 and renumber the rest [78:10+]: "(7) An implied-DO variable within an array constructor where the bounds and strides of the corresponding implied-DO are initialization expressions, or" 7. In section 7.1.6.2, in the list, in item 5 [79:4], change: "either restricted expressions or implied-DO variables," to: "restricted expressions," 8. In section 7.1.6.2, in the list, in item 9 [79:15], delete the last "or" 9. In section 7.1.6.2, in the list, add as item 10 and renumber the rest [79:15+]: "(10) An implied-DO variable within an array constructor where the bounds and strides of the corresponding implied-DO are restricted expressions, or" SUBMITTED BY: Janice C. Shepherd HISTORY: 93-027 Submitted 93-088 Draft response approved 93-111 m125 ballot approved with Martin, Rolison edits 94-160 m129 WG5 ballot, failed 94-181r2 m129 reversed response, approved u.c. 94-221 m130 X3J3 ballot failed 22-1 94-244 m130 Edits revised. Approved u.c. 94-306 m131 X3J3 ballot, approved 19-0 -------------------------------------------------------------------------------- NUMBER: 000135 TITLE: INTENT(IN) conformance KEYWORDS: INTENT(IN) attribute, conformance DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Section 1.4, Conformance, states "An executable program (2.2.1) is a standard-conforming program if it uses only those forms and relationships described herein and if the executable program has an interpretation according to this International Standard." Consider the following fragment: SUBROUTINE A (X) INTENT(IN) :: X IF (expr) X = 1.0 The intent attribute (5.1.2.3) specifies that X must not be redefined or become undefined during the execution of the procedure. Does the use of X in this fragment meet both conformance requirements -- using only those forms and relationships described herein -- the executable program has an interpretation (assume that "expr" is false) according to this International Standard? If "yes", was it the intent of the standard that a conforming processor not reject this program until X=1.0 is executed? ANSWER: No, the use of X in this fragment does not meet the conformance requirements of using only forms and relationships described in the standard. However, the existing wording of the standard could be interpreted to imply that the fragment was conforming if "expr" were always false. The edits below clarify that the fragment is non-conforming whether or not "X=1.0" is executed, and apply equally to the INTENT attribute in a type declaration statement and the INTENT statement. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.2.1 and 14.7.5 EDITS: 1. Section 5.1.2.3 following R511 - add the following constraint after the existing constraint [44:24+]: "Constraint: A dummy argument with the INTENT(IN) attribute, or subobject of such a dummy argument, must not appear in the following contexts: (1) As the of an , (2) As a DO variable or implied-DO variable, (3) As an in a , (4) As a in a if the appears in a NML= specifier in a , (5) As an in an , (6) As an IOSTAT= or SIZE= specifier in an input/output statement, (7) As a definable variable in an INQUIRE statement, (8) As a in an or , (9) As an actual argument in a reference to a procedure with an explicit interface when the associated dummy argument has the INTENT(OUT) or INTENT(INOUT) attribute, or <<(10) In an .>>" SUBMITTED BY: Dick Weaver HISTORY: 93-156 m125 initial submission 93-191 m126 proposed response 93-208 m126 revised response, approved uc 93-255r1 m127 ballot failed 21-3 93-326 m127 response approved uc 94-034 m128 X3J3 ballot failed 25-2 94-091 m128 additional edit supplied, approved 16-1 94-116 m129 X3J3 ballot failed 10-13 94-274r1 m130 Revised response, approved u.c. 94 m131 X3J3 ballot approved 19-0 -------------------------------------------------------------------------------- NUMBER: 000137 TITLE: array-element in data-implied-do KEYWORDS: DATA statement DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: R536 states that an can be a . 5.2.9, first paragraph following the constraint, states "A variable ... must not be initialized more than once in an executable program." Thus (A(2), I = 1,1) is conforming while (A(2), I = 1,2) is not conforming Is there a constraint missing, along the lines of s and s that are s must each have at least one subscript whose value is a function of the . ANSWER: No. There is no constraint missing. Discussion: The first implied-DO was standard conforming in FORTRAN 77, and continues to be in Fortran 90. EDIT: None SUBMITTED BY: Dick Weaver HISTORY: 93-158 m125 submitted 94-046r1 m128 response approved 10-4 94-116 m129 X3J3 ballot failed 12-11 94-291 m130 alternate response, approved u.c. 94-306 m131 X3J3 ballot approved 18-1 -------------------------------------------------------------------------------- NUMBER: 000139 TITLE: INTRINSIC, EXTERNAL attribute questions KEYWORDS : INTRINSIC attribute, EXTERNAL attribute, conformance DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Section 5.1.2.11 "INTRINSIC attribute" states The INTRINSIC attribute specifies that an object name in a declaration containing this attribute must be the specific or generic name of an intrinsic function... Section 5.1.2.10 "EXTERNAL attribute" has similar wording Question 1: Given REAL, INTRINSIC :: SIN REAL, EXTERNAL :: ABC Are SIN and ABC object names? If so, of what objects? Question 2: Given LOGICAL, INTRINSIC :: SIN What entity is being declared with the type 'LOGICAL'? ANSWER: Answer 1: SIN and ABC are not object names. The standard should not have used 'object name' in sections 5.1.2.10 and 5.1.2.11, but the name of the appropriate syntactic class. The edits below correct these sections. Answer 2: No entity is being declared with the type LOGICAL. Specifying a data type for a generic intrinsic function does not, in itself, remove the generic property from that function (section 5.1, [40:36-38]). There is no requirement for the data type specified in such a case to be one of the return types of the generic intrinsic. REFERENCES: 93-006R 000066 EDITS: 1. Section 5.1.2.10 Replace 'an object name' with 'a function name' [48:26] 2. Section 5.1.2.11 Replace 'an object name' with 'a function name' [48:30] SUBMITTED BY: Dick Weaver X3J3/93-160 HISTORY: 93-160 m125 Submitted 93-183 m125 response withdrawn 93-314r1 m127 response withdrawn 94-209 m129 minor changes to response, failed 9-10 Current version is 93-314r1. 3rd and 4th edits should be dropped. 94-292 m130 reversed answer 2 and reduced to 2 edits; approved u.c. 94-306 m131 X3J3 ballot approved 18-1 -------------------------------------------------------------------------------- NUMBER: 000140 TITLE: TARGET attribute for a derived-type object with a pointer component KEYWORDS: POINTER attribute, TARGET attribute, structure, structure component DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: Section 6.1.2 (page 63) states: A structure component has the INTENT, TARGET, or PARAMETER attribute if the parent object has the attribute. A constraint following R505 (page 40) states: Constraint: If the POINTER attribute is specified, the TARGET, INTENT, EXTERNAL, or INTRINSIC attribute must not be specified. This would seem to imply that a derived-type object with a pointer component could not have the TARGET attribute. Though it is informative, Annex C.4.6 (page 267) contains the following example: TYPE CELL INTEGER :: VAL TYPE (CELL), POINTER :: NEXT_CELL END TYPE CELL TYPE (CELL), TARGET :: HEAD TYPE (CELL), POINTER :: CURRENT ... CURRENT => HEAD which allows the static head of a linked list or tree. Does the structure component HEAD % NEXT_CELL contradict the text cited above from section 6.1.2 or the cited constraint following R505? ANSWER: Yes, the text from section 6.1.2 is contradicted and is in error. An edit is provided to correct the error. Discussion: The meaning of a pointer assignment must not be ambiguous, and this requires that a given data entity not have both the TARGET and POINTER attributes. The edit allows a structure to have the TARGET attribute, which conveys that attribute to the nonpointer components. The pointer components have the POINTER attribute only. REFERENCES: ISO/IEC 1539:1991 (E) sections 5.1, 6.1.2, 6.3.1.2 EDITS: In section 6.1.2, in the last paragraph before the last example, [63:15-17] change the sentence that starts: "A structure component has the INTENT..." to: "A structure component has the INTENT or PARAMETER attribute if the parent object has the attribute. A structure component that does not have the POINTER attribute has the TARGET attribute if the parent object has the TARGET attribute." SUBMITTED BY: J. Martin in response to email May 7, 1993 from Yukimasa Yoshida HISTORY: 93-179 m125 cancelled, interpretation number then reassigned 93-181 m125 Response, Withdrawn to remove suggested edit. 93-223r m126 Response proposed, approved uc 93-255r1 m127 ballot failed 18-5 94-339 m131 Revised response proposed, approved 14-2 95-034r1 m132 X3J3 ballot failed 8-12 -------------------------------------------------------------------------------- NUMBER: 000141 TITLE: Generic name same as specific name KEYWORDS: generic name, specific name DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Is there a conflict between the rule given in section 14.1.2, page 241, lines 29-31, and that given in section 12.3.2.1, page 168, lines 37-39, as they apply to generic and specific names? DISCUSSION: In a generic interface block, if a specific name is an external procedure, then it is a global entity. The generic name is a local entity of class 1. Section 14.1.2, lines 29-31, page 241 states: "Except for a common block name (14.1.2.1) or an external function name (14.1.2.2), a name that identifies a global entity in a scoping unit must not be used to identify a local entity of class (1) in that scoping unit." From the reference given for external function name (14.1.2.2), it appears that the exception is meant to apply only within the external function itself. From the text in 14.1.2, one might conclude that a generic name cannot be the same as one of the specific procedure names specified in the interface block. However, 12.3.2.1, page 168, lines 37-39 states explicitly that "a generic name may be the same as any one of the procedure names in the interface block..." ANSWER: The text in 14.1.2 was intended to allow this case. An edit is provided to clarify this. EDIT: In 14.1.2, paragraph 2, line 1 [241:29], before "or" add ", an external procedure name that is also a generic name (12.3.2.1),". SUBMITTED BY: T. Lahey and M. Snyder HISTORY: 93-188 m126 submitted 94-308 m131 proposed response 94-358 m131 clarified text of question, approved u.c. 95-034r1 m132 X3J3 ballot approved 20-0, with edit -------------------------------------------------------------------------------- NUMBER: 000143 TITLE: Use association and functions/subroutines/intrinsics KEYWORDS: use association, function, type declaration, subroutine, intrinsic procedure, external procedure DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: In Fortran programs it is sometimes the way an entity is referenced that partially determines what the entity is. For example given the following specification section: INTEGER X it is not clear until X is referenced as to whether X is the name of a function or the name of a variable. If such a specification statement appears in the scope of a module, can a reference to the entity by use association partially determine what the entity is? Section 11.3.2 indicates that the local name of an entity made accessible by use association may appear in no other specification that would cause any attribute of the entity to be respecified in the scoping unit (except the local name can appear in a PUBLIC or PRIVATE statement if the scoping unit is a module). But this section does not comment on the following example: MODULE M1 IMPLICIT INTEGER(A) INTEGER UNCLEAR1, UNCLEAR2 EXTERNAL ALSO_UNCLEAR ! Could be a subroutine or a function INTEGER SIN ! Could be a variable or an intrinsic CONTAINS SUBROUTINE XX(I) I = UNCLEAR1() ! Indicates UNCLEAR1 ! is a function not a variable. END SUBROUTINE END MODULE USE M1 WRITE(6,*) UNCLEAR1(), UNCLEAR2(), ALSO_UNCLEAR() END ANSWER: No. Discussion: The text of 11.3.2 cited addresses attributes being specified in specification statements. The text however does not consider the classification of a procedure as a function or a subroutine as can be specified by executable statements. It was the intent that attributes of all use associated entities and the classification of use associated procedures be specified within the scope of the module. An exception was made for the PUBLIC and PRIVATE attributes. An edit is provided to clarify the intent. EDIT: In section 11.3.2, ahead of "Examples:" add 2 new paragraphs [158:41+]: "A procedure with an implicit interface and public accessibility must explicitly be given the EXTERNAL attribute in the scoping unit of the module; if it is a function, its type and type parameters must be explicitly declared in a type declaration statement in that scoping unit. An intrinsic procedure with public accessibility must explicitly be given the INTRINSIC attribute in the scoping unit of the module or be used as an intrinsic procedure in that scoping unit." SUBMITTED BY: Janice C. Shepherd HISTORY: 93-190 m126 submitted 93-316 m127 response approved uc 94-034 m128 X3J3 ballot failed 22-6 94-242r1 m130 revised text and edit; approved u.c. 94-306 m131 X3J3 ballot approved 18-1 -------------------------------------------------------------------------------- NUMBER: 000145 TITLE: Expressions in of a FUNCTION statement KEYWORDS: expression - specification, expression - initialization, FUNCTION statement, host association, use association DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: The syntax rule R1217 shows that the type and type parameters of a function can be specified in the FUNCTION statement (12.5.2.2). (a) If a appears in a FUNCTION statement, can the initialization and specification expressions of that involve names of entities that are declared within the function or are accessible there by host or use association? (b) Section 5.1 states: "The (7.1.6.2) of a (5.1.1.5) or an (5.1.2.4) may be a nonconstant expression provided the specification expression is in an interface body (12.3.2.1) or in the specification part of a subprogram." As a FUNCTION statement is not part of the specification part of a subprogram, this text in the standard appears to distinguish between FUNCTION statements that are in interface blocks and ones that are not. This text seems to prohibit such examples as: INTEGER I ... CONTAINS CHARACTER*(I+1) FUNCTION F() ... COMMON // I ... where it can be confusing as to which I is being referenced in the FUNCTION statement. While host association does not apply to interface bodies, for consistency should the text quoted from Section 5.1 have been "... is in the specification part of an interface body (12.3.2.1) or in the specification part of a subprogram."? (c) Section 7.1.6.1 states: "If an initialization expression includes a reference to an inquiry function for a type parameter or an array bound of an object specified in the same , the type parameter or array bound must be specified in a prior specification of the ." Was this text intended to apply to FUNCTION statements even though they are not part of any , thus disallowing fragments such as: INTEGER (KIND=KIND(X)) FUNCTION F() INTEGER(KIND=KIND(0)) X ... Similar text appears in Section 7.1.6.2. ANSWER: (a) A specification expression in the of a FUNCTION statement may involve names of entities that are declared within the function or are accessible there by host or use association, but an initialization expression in such a may only involve names that are accessible by host association. (b) No. It was not the intent of the standard to distinguish between the two types of FUNCTION statements cited. As elaborated in the discussion of part (a), the standard intended to allow the expression of a FUNCTION statement to be a nonconstant expression. The sentence cited is corrected with a supplied edit. (c) Yes, the text cited from 7.1.6.1 was intended to apply to FUNCTION statements. The sentence quoted and the corresponding sentence in 7.1.6.2 are corrected with supplied edits. The code fragment is not standard conforming. Discussion: (a) An initialization expression is a constant expression with an additional rule relating to exponentiation (7.1.6.1). Since it is a constant expression, the only names it can contain are the names of named constants, structure constructors, intrinsic procedures, and variables whose type parameters or bounds are inquired about. * Named constant Section 5.2.1.1 states: A named constant must not be referenced in any ... context unless it has been defined in a prior PARAMETER statement or type declaration statement using the PARAMETER attribute, or made accessible by use association or host association. Since the FUNCTION statement is the first statement of the scoping unit, there can be no prior PARAMETER statement or type declaration statement using the PARAMETER attribute, so the first clause does not apply. Likewise, no USE statement could have occurred so use association does not apply. This means that if a named constant appears in the of a FUNCTION statement, the function must be a module procedure or an internal subprogram, and the named constant must exist in (be accessible from) the host scoping unit. This also means that a named constant must not appear in a of a FUNCTION statement of an interface body because an interface body does not access names via host association. * Structure constructor Rule R502 shows that the only opportunities for expressions to appear in s are in a or in a . However, a structure constructor can not appear in a because rule R505 shows that a must be an integer expression. Similarly, R506 shows that any initialization expression in a must be type integer. Therefore, a structure constructor can not appear in an initialization expression in the of a FUNCTION statement. * Intrinsic procedure The intrinsic procedure names or classes of intrinsic procedures that may appear in an initialization expression are given in 7.1.6.1. * Variables whose type parameters or bounds are inquired about The text from section 7.1.6.1 as cited in question (c) was intended to apply to initialization expressions in the of a FUNCTION statement. With the correction supplied, this means that if a variable appears as the argument to an inquiry intrinsic in the of a FUNCTION statement, the function must be a module procedure or an internal procedure, and the variable must exist in (be accessible from) the host scoping unit. Rule R502 defines . The only opportunity for a to contain a is when the data type is character ( may be a ). Section 7.1.6.2 states that a specification expression is a restricted expression that is scalar, of type integer, and each operation must be intrinsic. In addition, rule (2) of 7.1.6.2 states that a primary of a specification expression can be a dummy argument that has neither the OPTIONAL nor INTENT(OUT) attribute. The following code fragment demonstrates a use of such a dummy argument: CHARACTER*(N+1) FUNCTION S(N) INTEGER, INTENT(IN) :: N Rule (2) also states that the primary can be a subobject of such a dummy argument. Section 6.1.2 indicates that a structure component must not be referenced or defined before the declaration of the parent object. Similar rules are needed to prevent a substring from being referenced ahead of the declaration of its parent, and an array element or array section from being referenced ahead of the declaration of the array. Edits are provided to supply these rules. Since a subobject can not be referenced before its parent object is declared and the FUNCTION statement is the first statement of the subprogram, the parent's declaration could not have occurred. Thus a subobject must not be referenced in the on a FUNCTION statement. Rule (3) states that a primary can be a variable that is in a common block. The following code fragment demonstrates a use of such a common block member: CHARACTER*(N+1) FUNCTION S() ... COMMON N As in rule (2), rule (3) allows a subobject of such a variable but for the same reasons as above, such a subobject designator can not appear in the expression of a FUNCTION statement. Rule (4) states that a primary may be a variable that is accessible by use association or host association. The following code fragments demonstrate uses of such variables: PROGRAM MAIN INTEGER :: N = 21 ... CONTAINS CHARACTER(LEN = 2*N) FUNCTION SS(K) ! N is host associated. ... END FUNCTION END PROGRAM and MODULE MOD INTEGER K DATA K /20/ END MODULE CHARACTER*(K*2) FUNCTION CHECK(STR) ! K is use associated. USE MOD ... END FUNCTION Rule (4) also states that the primary can be a subobject of such a use or host associated variable, but by the same reasoning as above, a subobject of a use associated variable can not appear in the expression. A structure constructor can not appear in a FUNCTION specification expression because the expression must be of type integer and any operations (which might yield an integer value from one or more structure constructors) must be intrinsic. Other rules of 7.1.6.2 state which intrinsic procedure names or classes of intrinsic procedures may appear in a specification expression. Section 7.1.6.2 also states: A variable in a specification expression must have its type and type parameters, if any, specified by a previous declaration in the same scoping unit, or by the implicit type rules currently in effect for the scoping unit, or by host or use association. The discussion above regarding specification expressions has already ruled out "previous declarations" so the first clause of the cited sentence does not apply. The other clauses apply equally to a FUNCTION statement and to type declaration statements inside the function. (b) When the discussion for part (a) is applied to the code fragment provided, it means that the 'I' referenced in the of the FUNCTION statement is the common block member. EDITS: 1. Section 5.1, in the first sentence of the paragraph that starts "The (7.1.6.2)" [40:39-41], change "in an interface body (12.3.2.1) or in the specification part of a subprogram" to "contained in an interface body (12.3.2.1), is contained in the specification part of a subprogram, or is in the of a FUNCTION statement (12.5.2.2)" 2. Section 6.1.1, add to the end of the paragraph before the examples [62:29] "A substring must not be referenced or defined before the declaration of the type and type parameters of the parent string, unless the type and type parameters are determined by the implicit typing rules of the scope." 3. Section 6.2.2, add after the sentence "An array section is an array." [64:16] "An array element or array section must not be referenced or defined before the declaration of the array bounds of the parent object." 4. Section 7.1.6.1, in the paragraph after the constraints [78:21-22] change "object specified in the same , the type parameter or array bound must be specified in a prior specification of the ." to "object declared in the same scoping unit, the type parameter or array bound must be specified in a specification prior to the initialization expression." 5. Section 7.1.6.2, in the 2nd paragraph after the constraint [79:28-29] change "entity specified in the same , the type parameter or array bound must be specified in a prior specification of the ." to "entity declared in the same scoping unit, the type parameter or array bound must be specified in a specification prior to the specification expression." SUBMITTED BY: Janice C. Shepherd HISTORY: 93-193 m126 submitted 94-023r1 m128 response, approved uc 94-116r1 m129 X3J3 ballot failed 22-1 94-336 m131 revised response, approved u.c 95-034r1 m132 X3J3 ballot failed 15-5 -------------------------------------------------------------------------------- NUMBER: 000146 TITLE: Intrinsic Type Names KEYWORDS: conformance, intrinsic type, derived type, names - class DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Section 1.4 "Conformance", third paragraph following the list, states: For example, a standard-conforming processor may allow a nonstandard data type. Section 4.4.1 "Derived-type definition", fifth constraint following R424, states: A derived type must not be the same as the name of any intrinsic type... Suppose the program fragment TYPE ABC INTEGER XYZ END TYPE is taken to a processor that, as allowed by 1.4, has defined the nonstandard intrinsic type "ABC". Is it intended that this processor reject the program for the reason that a derived type , ABC, is the same as the name of a nonstandard intrinsic type? ANSWER: No. Vendor-specific types which behave like intrinsic types are not strictly intrinsic types, because the entire list of intrinsic types is enumerated in section 4. Section 4 states: "An intrinsic type is one that is predefined by the language." EDITS: None SUBMITTED BY: Dick Weaver HISTORY: X3J3/93-209 m126 submitted X3J3/93-317 m127 response approved uc 94-034 m128 X3J3 ballot failed 25-2 94-340 m131 Revised response submitted, approved u.c. 95-034r1 m132 X3J3 ballot approved 19-1, with edit -------------------------------------------------------------------------------- NUMBER: 000147 TITLE: Generic name resolution KEYWORDS: generic name DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Consider the following program : PROGRAM EX1 INTERFACE SQRT REAL FUNCTION USERSQRT(I) INTEGER I END FUNCTION USERSQRT END INTERFACE CALL TEST CONTAINS SUBROUTINE TEST INTRINSIC SQRT WRITE(*,*) SQRT(16) END SUBROUTINE TEST END According to the standard (section 14.1.2.4) the name SQRT is both generic in TEST (since it is a generic intrinsic) and in the host scope EX1 since it is a generic user procedure. According to 14.1.2.4.1 the reference to SQRT(16) should resolve to USERSQRT; i.e. even though the user specifies intrinsic for SQRT the user ends up with a reference to a user procedure. Contrast that with the following example where SQRT has been replaced by CSQRT: PROGRAM EX2 INTERFACE CSQRT COMPLEX FUNCTION USERSQRT(I) INTEGER I END FUNCTION USERSQRT END INTERFACE CALL TEST CONTAINS SUBROUTINE TEST INTRINSIC CSQRT WRITE(*,*) CSQRT(16) END SUBROUTINE TEST END In this case CSQRT is the name of a specific intrinsic procedure and the reference CSQRT(16) is according to 14.1.2.4.2 to that procedure, which since the argument type is integer, is invalid. By changing from a generic to a specific intrinsic name, the call resolution changes drastically which a user could find very confusing - it seems that the INTRINSIC attribute confers different properties in the two cases. Is this interpretation of the standard correct? If so, was this the intended behavior? ANSWER: Yes, the interpretation of the standard is correct. Yes, it was the intended behavior. Discussion: In the first example, SQRT is established to be a generic name. The resolution of a reference to a generic name is specified in 14.1.2.4. In the second example, CSQRT is established to be a specific intrinsic name within the internal procedure. In a reference to a specific intrinsic, any arguments specified must match those expected by the specific intrinsic. EDITS: None. SUBMITTED BY: Graham Barber HISTORY: 93-202 m126 submitted 94-294 m130 response approved u.c. 94-306 m131 X3J3 ballot approved 19-0 -------------------------------------------------------------------------------- NUMBER: 000148 TITLE: RANDOM_SEED, RANDOM_NUMBER KEYWORDS: RANDOM_SEED intrinsic, RANDOM_NUMBER intrinsic DEFECT TYPE: Erratum STATUS: X3J3 consideration in progress QUESTION: (1) After executing the following sequence : CALL RANDOM_SEED CALL RANDOM_NUMBER(X) CALL RANDOM_SEED CALL RANDOM_NUMBER(Y) is it the intent of the standard that X=Y? The description of RANDOM_SEED, section 13.13.84 (page 228), specifies that if no argument to RANDOM_SEED is present the processor sets the seed to a processor-dependent value. Was it the intent that the same processor-dependent value be set into the seed on all such argumentless calls to RANDOM_SEED? (2) After executing the following sequence: INTEGER SEED(2) CALL RANDOM_NUMBER(X1) CALL RANDOM_SEED(GET=SEED) CALL RANDOM_NUMBER(X2) CALL RANDOM_SEED(PUT=SEED) CALL RANDOM_NUMBER(X3) is it the intent of the standard that X2=X3? i.e. that the seed is updated on each call to RANDOM_NUMBER and that by restoring the seed value to that before the last call of RANDOM_NUMBER the last number will be generated again. There is nothing in the standard that specifies this behavior. An alternative implementation that conforms to the current standard does not update the seed on each call to RANDOM_NUMBER. Rather the put argument to RANDOM_SEED effectively initializes a sequence of numbers and remains unchanged until the next put. Whenever a put is done with a given seed the same sequence of numbers will always be generated. If a different seed is put a different seed will be generated. With this approach the value X3 has the same value as X1, not X2. ANSWER: (1) This is processor dependent. The standard states: "If no argument is present, the processor sets the seed to a processor dependent value." [228:13] This leaves the value of the seed and the method of generating that value up to the processor. Therefore, it is not possible to say whether X = Y or not. Different processors will handle this in different ways. (2) Yes. It is the intent of the standard that X2=X3. An edit is supplied to clarify that this is the intent. EDIT: In section 13.9.2 add the following text after the last sentence of the section [188:7+] "The pseudorandom number generator accessed by RANDOM_SEED and RANDOM_NUMBER maintains a seed that is updated during the execution of RANDOM_NUMBER and that may be specified or returned by RANDOM_SEED. Following execution of the statements CALL RANDOM_SEED(PUT=SEED1) CALL RANDOM_SEED(GET=SEED2) SEED1 need not equal SEED2. However calls to RANDOM_NUMBER immediately after a call to RANDOM_SEED with a seed that is either SEED1 or SEED2 return the same sequence of pseudorandom numbers. In particular, after subsequent execution of the statements CALL RANDOM_NUMBER(X1) CALL RANDOM_SEED(PUT=SEED2) CALL RANDOM_NUMBER(X2) X1 equals X2." SUBMITTED BY: Graham Barber HISTORY: 93-203 m126 submitted 94-051r2 m128 response, approved uc 94-116 m129 X3J3 ballot failed 12-11 94-201 m129 revised response and added edit, approved u.c. 94-221 m130 X3J3 ballot failed 21-2 94-325 m131 revised response, approved 16-1 95-034r1 m132 X3J3 ballot failed 13-7 -------------------------------------------------------------------------------- NUMBER: 000149 TITLE: Statement Function - Array constants in expressions, "composed" KEYWORDS: statement function, primary DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: In section 12.5.4, the first constraint, it states: "... may be composed only of ...." does "composed" mean the primaries of that expression or does it extend to primaries of contained expressions? ANSWER: "Composed" is not defined by the standard. An edit is provided that eliminates the use of "composed". EDIT: In section 12.5.4, in the first sentence of the first constraint, [182:4] change "The may be composed only of" to "The primaries of the must be". SUBMITTED BY: Dick Weaver HISTORY: 93-222 m126 submitted 94-341 m132 Question revised, response submitted, approved u.c. 95-034r1 m132 X3J3 ballot approved 20-0, with edit --------------------------------------------------------------------------------