From martin@ocfmail.ocf.llnl.gov Wed Nov 30 03:13:08 1994 Received: from ocfmail.ocf.llnl.gov by dkuug.dk with SMTP id AA15290 (5.65c8/IDA-1.4.4j for ); Wed, 30 Nov 1994 20:13:13 +0100 Received: by ocfmail.ocf.llnl.gov (4.1/SMI-4.0) id AA17224; Wed, 30 Nov 94 11:13:08 PST Date: Wed, 30 Nov 94 11:13:08 PST From: martin@ocfmail.ocf.llnl.gov (Jeanne T Martin) Message-Id: <9411301913.AA17224@ocfmail.ocf.llnl.gov> To: sc22wg5@dkuug.dk Subject: N1070 X-Charset: ASCII X-Char-Esc: 29 ------------------------------------------------------------------------------- NUMBER: 000028 TITLE: Host association and Implicit type rules KEYWORDS: use association, host association, implicit typing DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION 1: Consider the following program fragment: MODULE A CONTAINS SUBROUTINE B(Z) IMPLICIT INTEGER (X) 10 Z = XXX !Local variable or invalid function reference? ... END SUBROUTINE REAL FUNCTION XXX() ... END FUNCTION END MODULE In the above example in statement 10, is XXX an implicitly typed scalar variable or an erroneous function reference to module procedure XXX? That is to say, does the syntax of the reference determine which entity is referenced? QUESTION 2: Consider the following program fragment: MODULE X INTEGER, DIMENSION(10) :: A ... CONTAINS SUBROUTINE Y() ... CONTAINS SUBROUTINE Z(I) 20 A(I) = I ! Host associated array reference ! or invalid reference to function A? END SUBROUTINE FUNCTION A(K) ! Hides array A in module spec part? ... END FUNCTION END SUBROUTINE END MODULE Is the reference to A in statement 20 a reference to the array A declared in the module specification or an invalid reference to the internal procedure A? ANSWER 1: The reference to XXX is an invalid reference to the host associated module procedure XXX. The syntax of the reference does not determine which entity is referenced. ANSWER 2: The reference to A is an invalid reference to the host associated internal procedure A. Discussion: Section 5.3, in the fourth paragraph beginning "Any data entity ...", defines which data entities are implicitly typed. This definition excludes variables made accessible by use association or host association. In the first example, a form of reference does not differentiate between a host associated entity and a local implicitly typed scalar. In the second example, within subroutine Y the definition of the internal procedure A makes the array A inaccessible by host association (section 12.1.2.2.1). The internal procedure A is accessible within subroutine Z by host association. The reference to A(I) in subroutine Z is an invalid reference to function A. EDITS: None. SUBMITTED BY: Jon Steidel, 120-JLS-6 (120.024)) HISTORY: 120-RL-3 (120.060) ui 105 ballot comments (jw note) 93-134 m125 unanimous consent 93-255r1 m127 ballot failed 23-1 93-329 m127 approved uc 94-034 m128 X3J3 ballot failed 26-2 94-106r1 m128 revised response, approved u.c 94-116 m129 X3J3 ballot failed 16-7 94-164 m129 clarify question and answer, approved u.c. 94-221 m130 X3J3 ballot approved 23-0 ------------------------------------------------------------------------------- NUMBER: 000030 TITLE: Length of character literals in array constructors KEYWORDS: array constructor, character DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Consider the following example: CHARACTER :: NAMES (3) * 20 NAMES = (/ 'TOM', 'DICK', 'HARRY' /) This appears to be invalid due to a constraint in section 4.5, "Construction of array values": Constraint: Each expression in the must have the same type and type parameters. The length of the string is a type parameter. Thus the array constructor sample above is invalid because the strings have different lengths. Consider another example: CALL SUB ( (/ 'TOM', 'DICK', 'HARRY' /) ) ... SUBROUTINE SUB (NAMES) CHARACTER :: NAMES(:) * (*) WRITE(*,*) LEN(NAMES) ... This also appears invalid. 1. Must each character string literal constant in an array constructor be the same length? 2. If the answer to 1 is "No", what values are printed by the second example? 3. If the answer to 1 is "Yes", another question arises. The syntax of an array constructor is described in section 4.5. In rule R432, is defined to be an or an . Since an may be an expression, a substring is a valid . Therefore each substring in an array constructor must have the same length and that length must be the same as the length of every other in the constructor. But a substring can contain nonconstant expressions as the starting point and ending point, or the starting point and ending point can be omitted (signaling the use of a default value). Since a substring can contain nonconstant starting and ending points, the constraint cited above cannot be detected at compile time and thus cannot be a constraint. Should this restriction be rephrased as prose in the text of the standard? ANSWER: The answer to question 1 is yes. Each character literal constant in an must be the same length. Both examples are nonstandard conforming. The answer to question 3 is yes. The following edits move the equal-length requirement from a constraint to prose in the text. Discussion: The awkwardness resulting from the requirement that each be the same length was noted by X3J3, but the committee could not reach agreement on an acceptable way to allow character literal constants of differing lengths in an . Since the length cannot always be determined at compile time, that part of the constraint must be changed to prose. EDITS: 1. In the second constraint following R435 [38:3-4] change: "the same type and type parameters." to: "the same type and kind type parameter." 2. Add the following paragraph after the constraints in 4.5. [38:4] If the expressions are of type character, each expression in the must have the same length type parameter. SUBMITTED BY: (Questions 1 and 2) Larry Rolison in 120-LRR-1 (120.026) (Question 3) Larry Rolison in X3J3/93-070 HISTORY: 120-LJO-1 (120.074) Response to Questions 1 and 2 - 93-070 m124 Question 3. submitted as 93-100 m124 proposed response, adopted by unanimous consent 93-111 m125 ballot approved with Rolison edit 94-160 m129 WG5 ballot, failed; 94-179 m129 minor edit changes 94-225r1 m130 adjust EDITS, as per WG5 ballot, approved u.c. 94-306 m131 X3J3 ballot approved 19-0 -------------------------------------------------------------------------------- NUMBER: 000041 TITLE: Procedure with target dummy argument requires explicit interface KEYWORDS: argument - dummy, interface - explicit, TARGET attribute DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 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: Section C.5.3 is in error by stating the TARGET attribute is solely to aid optimization. The supplied edit corrects the error. Discussion: Defect item 000125 supplies edits to make it clear that: If the dummy argument has the TARGET attribute and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript: (1) Any pointers associated with the actual argument become associated with the corresponding dummy argument on invocation of the procedure. (2) When execution of the procedure completes, any pointers associated with the dummy argument remain associated with the actual argument. In this case, the simple argument association mechanism that involves supplying only the location of the first storage unit of the argument or of a copy of the argument (see C.12.5) is not adequate at the point of reference. In particular, the location of the actual argument and details of its layout in storage may need to be available within the called routine to ensure that the pointer association works as described. EDIT: Section C.5.3, second sentence, change "solely" to "primarily". [269:21] SUBMITTED BY: K. Kazumura, X3J3/92-048 (121-ADT-8) page 23 HISTORY: Posted request to f90 interp e-mail ui 82, ui 111, ballot, 92-329 (jw note) 92-070 m121 Approved m123 Approval rescinded (uc) 93-101 m124 Revised response adopted by uc 93-111 m125 ballot approved m128 Status changed to "consideration in progress" as this refers to edits in 000121 that no longer exist 94-235 m130 draft revision, approved uc 94-306 m131 X3J3 ballot approved 18-1 -------------------------------------------------------------------------------- NUMBER: 000049 TITLE: Characteristics of function results KEYWORDS: characteristics, function result, ENTRY statement, exact dependence, association - partial, association - entry DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 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 sentence containing the phrase "the exact dependence on the entities" in section 12.2.2 is intended to convey that in those cases where the shape or character length type parameter is not constant, the corresponding characteristic of the function result is not a value but the way the value is determined when the procedure is invoked. Discussion: Only the mapping from program state to value is significant, not the particular form in which that mapping is expressed. In question 3, for example, it is a characteristic of FUN and ENT that their lengths are twice the value of M. It is not required that the expressions of this mapping be identical, only that they yield the same results. Thus, twice the value of M could be expressed as M+M for FUN and as M*2 for ENT. The phrase "the exact dependence on the entities in the expression is a characteristic" is used to give the processor the freedom to evaluate lengths and bounds in any convenient manner. Since the characteristics must be the same, the phrase implies, as a minimum, that the expressions be algebraically equivalent and use the same variables. In an example such as: FUNCTION FUN(M) CHARACTER (LEN=M)::FUN CHARACTER (LEN=M + 0*K)::ENT ... ENTRY ENT(M, K) ... END FUN and ENT do not have the same characteristics since their dependence on "K" is different. Indeed, if on entry to FUN the length of FUN or ENT were evaluated using the expression for the length of ENT the evaluation would fail since K is not associated with a value. Clearly, it can be extremely difficult to determine on a static basis whether two expressions of a mapping are consistent, and there is no requirement in the standard that this be done. It would be possible to check during execution that the values expressed are identical each time such a procedure is invoked, but it is expected that a more typical application of this requirement would be to assume that it has been met and use one expression of this mapping as the basis for computing attributes of all of the result variables. REFERENCES: ISO/IEC 1539:1991 (E) section 12.2.2 & 14.6.3.3 EDITS: None SUBMITTED BY: Y. Yoshida, X3J3/92-051 (121-ADT-11) pp.-13 HISTORY: 92-109A m121 Approved 19-0 92-313 m123 response to ballot comments and approved by uc 93-105 Revised in response to ballot comments 93-152 m125 New edit, rejected 94-059 m128 New edit, 94-252 m130 New response without edits, approved u.c. 94-306 m131 X3J3 ballot approved 18-1 -------------------------------------------------------------------------------- NUMBER: 000086 TITLE: USE and host association KEYWORDS: use association, host association, generic interface, EXTERNAL statement DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Use association, 11.3.2 states The USE statement provides the means by which a scoping unit accesses named data objects, derived types, interface blocks, procedures, generic identifiers (12.3.2.1), and namelist groups in a module. Host association, 12.1.2.2.1 states An internal subprogram, a module subprogram, or a derived-type definition has access to the named entities from its host via host association. The accessed entities are known by the same name and have the same attributes as in the host and are variables, constants, procedures including interfaces, derived types, type parameters, derived-type components, and namelist groups. Question 1: Do use and host association access the same entities? What entities does each access? Question 2: For both use and host association, what entities are not accessed? Question 3: For host and use association, if the host or module referenced contains an EXTERNAL statement for ABC, is ABC an accessed entity that has the EXTERNAL attribute? Note that an EXTERNAL statement is not a "named entity" (the statement has no name) and the procedure named in the statement is not in the host or module (that is the reason for the EXTERNAL statement). The answer to question 1 or 2 should also answer this question. Question 4: Given the following PROGRAM A MODULE M USE X USE Y CONTAINS SUBROUTINE B USE M is subprogram B associated in some way with X? What way? Note that A, the host of B, "accesses" entities in X by use association; the entities in X are not "in" B's host. Question 5: In the same example, is subprogram B associated in some way with Y? What way? As with question 4 note that the entities in Y are "accessed" from M; the entities in Y are not in M and use association refers to the entities "in the module". Question 6: Given the following: MODULE A ! level 1 host USE AA INTERFACE F ... CONTAINS SUBROUTINE B ! module subroutine, level 2 host USE BB INTERFACE F .... CONTAINS SUBROUTINE C ! internal subprogram USE CC INTERFACE F ... .... = F(X) ! an invocation of the generic name F and where modules AA, BB, and CC all contain a generic interface for F: How is the invocation of the generic name F resolved? (in what sequence are the host scopes and the modules used considered?) Note the levels of nesting: A contains B contains C. Section 14.1.2.4.1, "Resolving procedure references to names established to be generic", (3), seems to consider only B, the host of C, and not A. ANSWER: Answer 1: Entities declared PRIVATE are potentially accessible by host association but not by use association. Otherwise, it was intended that the classes of entities made accessible by these two forms of association be the same. These are named data objects (including both constants and variables), derived types, derived type components, procedures (both those defined in the host or module and those declared there and defined elsewhere; both those identified by names and those identified by other generic identifiers), and namelist groups. See sections 12.1.2.2.1 and 11.3.2. While the words used to describe the classes of accessible entities are not identical the meaning behind the words is the same. Future versions of the standard should endeavor to use the same words for these two lists. Answer 2: Entities not in the list in 12.1.2.2.1 and 11.3.2 are not made accessible. For example, FORMAT statement labels, construct names, and common block names are not made accessible. Answer 3: In such an example, ABC would be accessible. Section 12.3.2.2 indicates that the EXTERNAL statement specifies a list of names that are procedures. In the host or module, ABC is the name of a procedure and thus is the name of a potentially accessible entity; it is not necessary that the definition of ABC be present in the host or module. Answer 4: The entities of module X made accessible in A by use association are made accessible in B by host association. Note that each such entity has a local name (or other identifier) in A. See Section 11.3.2. Answer 5: The entities of module Y made accessible in M by use association are made accessible in B by use association. Note that each such entity has a local name (or other identifier) in M. See Section 11.3.2. Answer 6: In effect, first C and CC are checked for a consistent specific interface, then B and BB, then A and AA, and finally (if F were the generic name of an intrinsic function) the intrinsics are checked. In applying 14.1.2.4.1 to a reference in C, item (1) provides the check of interfaces in C (including those made accessible from CC), and item (3) provides for a recursive application of 14.1.2.4.1 to B. In this recursive application, (1) checks B (and BB), and (3) results in a further recursive application of 14.1.2.4.1 to A. In this application, (1) checks A (and AA), (3) is not applicable, and (4) checks the intrinsics. 14.1.2.3 establishes that there must be no ambiguity in distinguishing the interfaces declared in C from those made accessible from CC. EDITS: None. SUBMITTED BY: Dick Weaver HISTORY: 92-214 Submitted 92-281 m123 Response proposed (11-7 was insufficient for approval) 93-030r1 Revised response proposed m124 Approved (15-1) 93-111 m125 ballot approved with Kelble, Leonard, Martin, Rolison edits 93-234 m126 edit replaced by that in item 82, approved uc Note: cannot go forward until 000082 does. 94-034 m128 Relying on edit in 000082 that has been removed, status changed to X3J3 consideration in progress 94-240r1 m130 Revised response with no edit, approved u.c. 94-306 m131 X3J3 ballot approved 19-0 -------------------------------------------------------------------------------- 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: 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: 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-306 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: 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: 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: 000177 TITLE: Structures in EQUIVALENCE lists KEYWORDS: derived type, EQUIVALENCE statement, SEQUENCE, pointer DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Section 5.5.1 "EQUIVALENCE statement" contains the following constraint [57:1-5]: Constraint: An must not be a dummy argument, a pointer, an allocatable array, an object of a nonsequence derived type or of a sequence derived type containing a pointer at any level of component selection, an automatic object, a function name, an entry name, a result name, a name constant, a structure component, or a subobject of any of the preceding objects. It seems that each of the phrases in the constraint is intended to be an independent phrase such that one could rewrite the constraint in columnar form: Constraint: An must not be a dummy argument, a pointer, an allocatable array, an object of a nonsequence derived type or of a sequence derived type containing a pointer at any level of component selection, an automatic object, a function name, an entry name, a result name, a name constant, a structure component, or a subobject of any of the preceding objects. When written in this form it seems that the phrase an object of a nonsequence derived type or of a sequence derived type containing a pointer at any level of component selection, is disallowing an object of nonsequence derived type that contains a pointer at any level of component selection as well as an object of sequence derived type that contains a pointer at any level of component selection. However, at least two existing Fortran 90 processors declare ANY object of a nonsequence derived type in an EQUIVALENCE list as being in error, obviously because the implementers split the above phrase into an object of a nonsequence derived type, an object of a sequence derived type containing a pointer at any level of component selection, What is the intent of the standard? ANSWER: The intent was for the latter. If the former had been intended, the wording would have been "an object of a derived type containing a pointer at any level of component selection". This is confirmed in C.5.5, line 4 [270:9]: "Structures that appear in EQUIVALENCE statements must be sequence structures.". Note that for COMMON there is a very clear restriction in 5.5.2 [58:33]: "Constraint: If a is of a derived type, it must be a sequence type (4.4.1)". An edit is supplied to make the intention clearer. EDIT: On page 57, line 2, [57:2] change "derived type or" to "derived type, an object" SUBMITTED BY: Larry Rolison HISTORY: 94-156 m129 submitted 94-287r1 m130 response, approved u.c. 94-306 m131 X3J3 ballot approved 19-0 -------------------------------------------------------------------------------- NUMBER: 000179 TITLE: DO variable with POINTER attribute KEYWORDS: DO variable, POINTER attribute DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: The first constraint following rule R822 states: Constraint: The must be a named scalar variable of type integer, default real, or double precision real. The definition of loop initiation (8.1.4.4.1) states: (2) The DO variable becomes defined with the value of the initial parameter 1. The definition of the execution cycle of a DO loop (8.1.4.4.2) states: (3) ... The DO variable, if any, is incremented by the value of the incrementation parameter 3. Consider the following program: INTEGER, POINTER :: ptr INTEGER, TARGET :: lcv ptr => lcv DO ptr = 1, 3 PRINT *, lcv END DO END Note that the DO variable has the POINTER attribute. The POINTER attribute does not seem to be prohibited for the DO variable, but when the DO variable has the POINTER attribute, it is unclear as to whether the DO variable is the pointer or the target of the pointer. That is, it is unclear as to whether the pointer or the target is to be "defined" (8.1.4.4.1) or incremented (8.1.4.4.2). Also consider the following modification of the above program: INTEGER, POINTER :: ptr INTEGER, TARGET :: lcv1, lcv2 lcv1 = 1 lcv2 = 4 ptr => lcv1 DO ptr = 1, 3 IF (...) ptr => lcv2 ! An alternate EXIT form? END DO END The standard does not seem to address what happens when the DO variable is switched to a different variable while the loop is active. Did the standard mean to allow a DO variable to have the POINTER attribute? ANSWER: No. This oversight has been remedied by an edit. Discussion: The description of the iterative form of the DO loop was essentially carried forward from the previous standard. It was an oversight to prohibit the DO variable from having the POINTER attribute. Prohibiting the POINTER attribute prevents the confusion that can arise as demonstrated by the example programs given above. EDIT(S): Section 8.1.4.1.1 following the first constraint following rule R822 [100:39+] insert the new constraint: Constraint: The must not have the POINTER attribute. SUBMITTED BY: Larry Rolison HISTORY: 94-226r1 m130 submitted, approved 10-1 94-306 m131 X3J3 ballot approved 19-0 -------------------------------------------------------------------------------- NUMBER: 000181 TITLE: in STOP and PAUSE statements KEYWORDS: STOP, PAUSE DEFECT TYPE: Interpretation STATUS: X3J3 approved; ready for WG5 QUESTION: Was it an oversight to allow named character constants in addition to character literals as the (R843) of STOP (section 8.4) and PAUSE (section 8.5) statements? ANSWER: No. It was intended that the be expanded from the forms allowed in FORTRAN 77. EDITS: None. SUBMITTED BY: Linda O'Gara HISTORY: 94-251 m130 submitted with suggested answer 94-271 m130 alternate answer proposed, approved u.c. 94-306 m131 X3J3 ballot approved 19-0 -------------------------------------------------------------------------------- NUMBER: 000182 TITLE: Intrinsics in statement functions KEYWORDS: statement function, interface - explicit DEFECT TYPE: Erratum STATUS: X3J3 approved; ready for WG5 QUESTION: Item 52 contains an edit to section 12.5.4 to add the following after the first sentence of the first constraint: [182:4] "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." This new text appears to disallow statement functions that were valid in FORTRAN 77. Consider the following code fragment which references the intrinsic INT. PROGRAM SF ISF(A) = INT(A) ... WRITE(6,*) ISF(2.3) END In Fortran 90 INT has an optional argument and thus must have an explicit interface (which it does have as it is an intrinsic and all intrinsics have explicit interfaces). The edited constraint, which indicates "the function must not require an explicit interface", means that this is a not a valid Fortran 90 statement function. Should the statement function shown be a valid Fortran 90 statement function? ANSWER: Yes. The statement function in the code fragment is a valid Fortran 90 statement function. Discussion: The edit in item 52 was included with the intent of limiting the definition of statement functions to mostly that which was provided by FORTRAN 77. By indicating that a function referenced in a statement function must not require an explicit interface, the intent was to prohibit the use of such functions as ones that have dummy arguments that are pointers or results that are pointers. Such functions did not exist in FORTRAN 77. It was not the intent to prohibit statement functions that were valid in FORTRAN 77. An edit is provided that corrects the edit from item 52. EDITS: Section 12.5.4. first constraint, in the second sentence, as supplied in corrigendum 1 [182:4] change "the function must not require an explicit interface or be a transformational intrinsic," to "the function, if it is not an intrinsic, must not require an explicit interface, the function must not be a transformational intrinsic," SUBMITTED BY: Janice C. Shepherd HISTORY: 94-263r1 m130 submitted with suggested answer, approved u.c. 94-306 m131 X3J3 ballot approved 19-0