From jwagener@amoco.com Sat Oct 14 00:56:00 1995 Received: from interlock.amoco.com (interlock.amoco.com [192.195.167.2]) by dkuug.dk (8.6.12/8.6.12) with SMTP id AAA11652 for ; Sat, 14 Oct 1995 00:55:46 +0100 From: jwagener@amoco.com Received: by interlock.amoco.com id AA11864 (InterLock SMTP Gateway 3.0 for sc22wg5@dkuug.dk); Fri, 13 Oct 1995 18:55:31 -0500 Message-Id: <199510132355.AA11864@interlock.amoco.com> Received: by interlock.amoco.com (Protected-side Proxy Mail Agent-3); Fri, 13 Oct 1995 18:55:31 -0500 Received: by interlock.amoco.com (Protected-side Proxy Mail Agent-2); Fri, 13 Oct 1995 18:55:31 -0500 Received: by interlock.amoco.com (Protected-side Proxy Mail Agent-1); Fri, 13 Oct 1995 18:55:31 -0500 X-Openmail-Hops: 1 Date: Fri, 13 Oct 95 18:54:08 -0500 Subject: suggested replacement for 1 of 7 Mime-Version: 1.0 To: sc22wg5@dkuug.dk Content-Type: text/plain; charset=US-ASCII; name="Text_1" Content-Transfer-Encoding: 7bit To WG5: Following is a suggested replacement for CD ballot comments message 1 of 7 that Miles distributed a few days ago. This replacement contains the following corrections to the list of 20 original US "Required Repairs": - item 1: a missing comma added - item 4: a clarifying clause added to the problem statement, and a capitalization error corrected - a note added after item 4 that provides a possible alternative solution to items 3 and 4 - item 9: "may become" changed to "becomes" - item 10: the location [61:10+] added and "which" replaced by "that" - item 12: "before [94:30] ..." (the rest of the sentence) replaced with "make it the second sentence of the paragraph." - item 13: first two lines, corrected, combined, the addition clarified that a new paragraph is intended, and ", if any," removed - item 14: comma added after (7.5.3.1)and a note added that there may still be a problem in this area - item 16: an "and" replaced by a comma and the syntax item put in pointed brackets - item 19: "[211:6-7]" replaced by "the three sentences on [211:5-7] beginning with 'Intrinsic', " - item 20: "Solution:s" replaced by "Solutions:" - the items listed as "Technical changes" were moved to the section entitled "Quality Imporvements" (2 of 7) - the items listed as "Editorial changes" were moved to the section entitled "Editorial Improvements: (3 of 7) - several spelling errors were corrected Jerry Wagener, for the US =================================================== Required Repairs 1. Problem (111:3): There is no constraint that requires the to be the same shape within a WHERE construct, nor a constraint that requires the array assignments within the WHERE construct to be the same shape as the . Proposed Solution: Add the following to section 7.5.3.1, [111,3+] If a contains a , a , or another then each within the must be the same shape. In each , the and the being defined must be arrays of the same shape. 2. Problem (48:19): This constraint implies that subroutines cannot be declared with EXTERNAL nor INTRINSIC attributes (constraint applies to EXTERNAL and INTRINSIC statements - as indicated in section 5.2 (57:14-17)). Proposed Solution: 48:19, section 5.1, after "entity" insert " in an " 3. Problem (51:15): The last sentence of (1) is inconsistent with the rest, as the rest deals with dummy arguments that may or may not be functions. If left as is some might think that the first part only deals with functions also. Proposed Solution: 51:15, section 5.1.1.5, last sentence of item (1) Replace the sentence with: "<>" 4. Problem (51:21): When an external function with character (*) type, is invoked, the scope of the invocation must not include a interface body for the function, as implied by other rules. (From defect item 70, which has status X3J3 consideration in progress). Proposed Solution: 51:21, section 5.1.1.5, end of item (3), add sentence "The interface for such a function cannot be specified in an interface body." [Note - it has subsequently been suggested that the proposed solutions to problems 3 and 4 be replaced by a single note following the list: "A function result for a dummy or external procedure cannot be specified with a character length parameter value of * in an interface body. The specifications in an interface body are required to be the same as those specified in the procedure definition, but to invoke a procedure whose definition specifies a character*(*) result, the calling routine is required to specify a result length other than *."] 5. Problem (53:40): There is no such syntax term as . Proposed Solution: 53:40, section 5.1.2.4, 1st paragraph, last sentence, Change "" to "" 6. Problem (122:36-37): CASE construct ranges will not have right semantics if EQ is not replaced with LE. (once on line 36 and once on line 37). Proposed Solution: 122:36-37 Change "EQ" to "LE" twice. 7. Problem (39:45-47): This definition of "Explicit initialization" does not include pointer initialization (as that does not give a pointer a value). Proposed Solution: Change [39:46] from "with a value but is" to read "with a value, or a pointer with a disassociated status; it is". 8. Problem (50:41, 3rd constraint): Can a dummy function with "*" length be described in an explicit interface. 50:41 indicates it can be, but 51:15 indicates it can not be. Proposed Solution: Change [50:41] last word "explicit" to "implicit". 9. Problem (56:11-17, 5.1.2.5 SAVE attribute): These two paragraphs don't seem to take into account situations where a pointer association status can become undefined as described in 14.6.2.1.3. Proposed Solution: Change [56:16] from "when" to "after". Add a new paragraph after [56:17] to read: "In both cases, the association status of a pointer with the SAVE attribute becomes undefined if the target becomes undefined (14.6.2.1.3 (3))." 10. Problem (61:10+ Section 5.2.10, after 2nd constraint): Constraint from F90 that disallowed: POINTER P(:) DATA P(3) / 4.5 / is not present in F95. Proposed Solution: Add the following constraint [61:10+]: "Constraint: A or a that appears as a shall not be a subobject of a pointer." 11. Problem (68:21-22, 68:26-27, 70:19-20, COMMON): There is a contradiction amongst these sentences as to whether default initialization of an item in COMMON is permitted (68:26-27,70:19-20) or not permitted (68:21-22). Decision not to permit default initialization of items in COMMON, means an edit is also needed to restrict items equivalenced with common from having default initialization. Proposed Solution: Delete the constraint in [68:26-27]. Delete item (4) in [70:19-20]. Add at the end of the paragraph in [70:25]: "Equivalence association shall not cause a derived-type object with default initialization to be associated with an object in a common block." 12. Problem (94:28-33, 7.1.6.2 Specification expression, last paragraph): The last sentence of this paragraph is too specific to inquiry functions. It should include specification functions also, to indicate that the following is valid: INTERFACE PURE FUNCTION F(I,J) INTEGER F, I(10), J INTENT(IN) I, J END FUNCTION END INTERFACE INTEGER IA(10), A(F(IA,IA(3))) Proposed Solution: At the end of 94:31 change the clause "the array bounds shall be specified in a prior declaration" to "the array shall be completely specified in prior declarations". On 94:33 add "reference" after "inquiry function". And then move the entire sentence to make it the second sentence of the paragraph. 13. Problem (95:8-13 Section 7.1.7, 5th paragraph): A function reference is not allowed to affect the evaluation of any other entity within the statement, without similar restriction on subroutines it is possible to have a defined assignment statement within a FORALL where order of execution affects result. Consider the following example, MODULE MOD TYPE DT INTEGER C END TYPE DT INTEGER :: ARR(3) = (/1,2,3/) END MODULE MOD PROGRAM P USE MOD INTERFACE ASSIGNMENT(=) ELEMENTAL SUBROUTINE DEFASSIGN(L, R) USE MOD INTEGER, INTENT(OUT) :: L TYPE (DT), INTENT(IN) :: R END SUBROUTINE DEFASSIGN END INTERFACE FORALL (I = 1:2) ARR(I) = DT(I+1) PRINT *, ARR END PROGRAM P ELEMENTAL SUBROUTINE DEFASSIGN(L, R) USE MOD INTEGER, INTENT(OUT) :: L TYPE (DT), INTENT(IN) :: R L = ARR(R%C) + 1 END SUBROUTINE DEFASSIGN If the call to DEFASSIGN for I=1 occurs before that for I=2, the value of ARR after the FORALL is (/3,4,3/); in the opposite order, the value is (/5,4,3/). Proposed Solution: Add a new paragraph after [116:2] "In a forall-assignment-stmt, a defined assignment subroutine shall not reference any variable that becomes defined or pointer-object that becomes associated by the statement." 14. Problem (95:12, 7.1.7, "Evaluation of operands", 5th paragraph, last sentence): The text was meant to refer to functions with subscripts and stride of a FORALL statement but currently refers only to the functions that appear in the of a FORALL statement. Proposed Solution: Change [95:12] "WHERE statement(..), or FORALL statement(..)" to "the mask expression in a WHERE statement (7.5.3.1), or the subscripts and stride in a FORALL statement (7.5.4)" [Note - subsequent comments suggest that there is still a problem in the area cover by problem 14.] 15. Problem (113:22-28 Section 7.5.4.1, Last pair of constraints after R753): The final two constraints of this section constrain the FORALL construct to a greater extent than the HPF language does. Proposed Solution: Delete these two constraints; delete the same two constraints in [117:24-28]. 16. Problem (115:30-116:2 Section 7.5.4.2.3, 3rd paragraph): The description of pointer assignment in FORALL is incomplete. As it stands, only the *expressions* within are pre-computed, not the pointer which will actually be assigned. Proposed Solution: Add text to [115:31] to read "evaluation of all expressions ... , the determination of any pointers within , and the determination..." 17. Problem (118:19-22 Section 7.5.4.4, 1st paragraph): The paragraph restricts multiple assignments to the same object, but doesn't restrict multiple pointer assignments to the same object. Proposed Solution: Before "whether" in [118:19] insert "or association of more than one target with the same pointer". Before "to the same" in [118:22] insert "or pointer assign". 18. Problem (201:37+, after item(5), and 201:38): From defect item 193 Can a pointer dummy argument with the OPTIONAL attribute that is not present, be passed to a non-pointer optional dummy argument? This would appear to be a reference of the pointer. Proposed Solution: Add new item after line 37: "(6) If it is a pointer, it shall not be supplied as an actual argument corresponding to a nonpointer dummy argument other than as the argument of the PRESENT intrinsic function." In line 38, change "in (5)" to "in the list" 19. Problem (211:5-7, 12.6 Pure Procedures, first note): This note indicates that all intrinsic functions are pure. Where is there normative text that shows that this is true? The text of this note also implies that a processor cannot provide an intrinsic function that is not pure nor a non-elemental intrinsic subroutine that is pure. Proposed Solution: Delete the three sentences on [211:5-7] beginning with "Intrinsic", and before the note add the following normative text: "All intrinsic functions specified in this standard are pure. The MVBITS intrinsic subroutine is pure; no other intrinsic subroutine specified in this standard is pure." 20. Problem There is disagreement on the meaning of the description of the interpretation of multiple USE statements. This disagreement is illustrated by the following example: USE MOD, ONLY: X, A => B USE MOD, Y => X One interpretation of the statement about concatenating the rename-lists and only-lists is that the above should be interpreted as concatenating only the renamings from the only-list: USE MOD, A => B, Y => X The other interpretation is that the entire only-list should be included (converting it to the form of a rename-list): USE MOD, X => X, A => B, Y => X The difference between these interpretations is the question of whether X in the module is accessible in the local scoping unit by only the name Y or by both X and Y. This should be decided and made unambiguous; two possible solutions are proposed. Proposed Solutions: Edits have been proposed in each direction; since there are other minor problems in the same general area, they are displayed as alternative complete replacements for the four paragraphs following the constraints in 11.3.2 [185:28-38] "renames only" version: A in a or is the local name for the entity whose name in the specified module is ; if no appears, the local name is the or . A USE statement without the ONLY option provides access to each public entity in the specified module. A USE statement with the ONLY option provides access to each entity, if any, that appears as a or in the . More than one USE statement for a given module may appear in a scoping unit. If one of the USE statements is without an ONLY qualifier, all public entities in the module are accessible and the s and renames in s are interpreted as a single concatenated . If all the USE statements have ONLY qualifiers, only those entities named in one or more of the s are accessible, that is, all the s are interpreted as a single concatenated . "entire " version: A in a or is the local name for the entity whose name in the specified module is ; if no appears, the local name is the or . A USE statement with the ONLY option provides access to each entity, if any, that appears as a or in the . A USE statement without the ONLY option provides access to each entity, if any, that appears as a in the . Additionally, it provides access to any public entity in the specified module that does not appear (1) as a in the of the USE statement or (2) as a or in either (a) an or (b) a of another USE statement in the same scoping unit referencing the same module; the local name for the entity is the same as its name in the module.