From Miles.Ellis@Educational-Technology-Resources-Centre.oxford.ac.uk Mon Oct 9 20:48:40 1995 Received: from oxmail2.ox.ac.uk (oxmail2.ox.ac.uk [163.1.2.1]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id UAA20077 for ; Mon, 9 Oct 1995 20:48:25 +0100 Received: from vax.ox.ac.uk by oxmail2 with SMTP (PP); Mon, 9 Oct 1995 20:47:30 +0100 Received: from 163.1.85.1 by vax.ox.ac.uk (MX V4.1 VAX) with SMTP; Mon, 09 Oct 1995 18:44:29 +0100 X-Sender: MELLIS@vax.ox.ac.uk Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 9 Oct 1995 18:45:25 +0100 To: sc22wg5 From: Miles.Ellis@Educational-Technology-Resources-Centre.oxford.ac.uk (Miles Ellis) Subject: CD Ballot Comments - 1 of 7 This is the first of seven messages which, yogether, contain the complete set of comments received by the SC22 Secretariat in the ballot to approve the Fortran 95 CD. As previously announced, there was one NO vote, from the US, which was accompanied by a large number of comments. The first set of substantive reasons for voting NO are appended to this message. Following that are two messages containing US proposals for (a) quality and (b) editorial improvements, respectively. These are followed by further messages containing the comments accompanying the YES votes submitted by France, Germany, Japan and the UK, respectively. All of the comments, other than those from France and Japan, are based on email versions sent to me; the French and Japanese ones were typed by me from the official ballot comments. I shall place these comments on the WG5 ftp server tomorrow, and hope to place a version of them there containing all the comments, merged and in sequential order, in the next few days . I shall announce its availability by email. Miles -------------- Reasons accompanying US NO vote ------------------------- Note that these are mainly based on email versions sent to the Convenor, but are believed to be the same as the "official" versions sent to the SC22 Secretariat 1. US NO vote reasons 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 d 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. (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." 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 may become 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: "Constraint: A or a which 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 al 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 before [94:30] "If a specification expresssion incudes shall be specified...". 13. Problem ( 48. 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 resul 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 after [116:2] "In a forall-assignment-stmt, a defined assignment subroutine, if any, 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 staatement(..)" to "the mask expression in a WHERE statement (7.5.3.1) or the subscripts and stride in a FORALL statement (7.5.4)" 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 ... and the determination of any pointers within pointer-object, 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 Proposed Solution: Delete [211:6-7] 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 Solution:s 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 apear 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 "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 i (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. Technical changes: [3:25] Add "MAXVAL, MINVAL, PRODUCT, SUM " to list. [Editor is given discretion to reorder list.] [223:22,23,24,25] Replace each of these lines with two lines identical to 224:4-5 or 224:6-7 except for the intrinsic function name and description. [250:38,253:20,257:26,265:30] Make identical to 249:33 or 253:20 except for the intrinsic function name and the section number. [250:44,253:26,257:35,265:36] Remove "(optional)". Editorial changes: [249:39] and [252:25] Remove "(optional)". [xiii:24] replace "blanks in edit descriptors" with "whether blanks are permitted within edit descriptors in free source form". [xiv:7] delete ", those with scalar dummy arguments,". [xiv:9] replace "they make it feasible to allow user-defined (pure) functions" with "it is reasonable to allow them". [xiv:20] delete "Finally, " and move xiv:20-22 to xiii:21+. [xiv:38] replace "forms" with "form". [1:15] remove ":"; 1:16,17 append "," to line; 1:18 append ", and" to line; 1:19 append "." to line. [1:2]1 remove ":"; [1:22,24,26,29,31,33] append "," to line; 1:34 append ", and" to line; 1:35 append "." to line. [4:30] add "Except where stated otherwise, such requirements and prohibitions apply to programs rather than processors.". [17:19] embolden "elemental". [33:4] replace "input arguments to intrinsics" with "actual arguments to intrinsic procedures". [33:12] replace "F" with "IF". [73:40] replace "contsruct" with "construct". [81:1] replace "processor defined" with "processor dependent". [94:14] delete entire line (one word) [63:26+] Add the following as a note: The following is an example of a mapping to a derived type that is inaccessible in the local scope: PROGRAM MAIN TYPE BLOB INTEGER I END TYPE BLOB IMPLICIT TYPE(BLOB) (A) TYPE(BLOB) :: B CALL STEVE CONTAINS SUBROUTINE STEVE INTEGER BLOB ... AA=B ... END SUBROUTINE STEVE END PROGRAM MAIN In the subroutine STEVE, it is not possible to explicitly declare a variable to be of type BLOB because BLOB has been given a different meaning, but implicit mapping for the letter A still maps to type BLOB, so AA is of type BLOB. [104:20] Replace "For example, in" with "In". Combine notes 7.37 and 7.38 into a single note. Combine notes 7.39 and 7.40 into a single note. 111:47] Replace "each" with "the". ======================================================================= Dr Miles Ellis CCCCCCCCCCC Director: Educational Technology Resources Centre C C University of Oxford, 37-41 Wellington Square C E Oxford OX1 2JF, ENGLAND C T C R Telephone: +44 1865 270528 Fax: +44 1865 270527 C C Email: Miles.Ellis@etrc.ox.ac.uk CCCCCCCCCCC =======================================================================