From jwagener@amoco.com Mon Apr 10 10:30:11 1995 Received: from interlock.amoco.com by dkuug.dk with SMTP id AA23490 (5.65c8/IDA-1.4.4j for ); Mon, 10 Apr 1995 22:31:17 +0200 Received: by interlock.amoco.com id AA05258 (InterLock SMTP Gateway 3.0 for sc22wg5@dkuug.dk); Mon, 10 Apr 1995 15:30:59 -0500 Message-Id: <199504102030.AA05258@interlock.amoco.com> Received: by interlock.amoco.com (Protected-side Proxy Mail Agent-3); Mon, 10 Apr 1995 15:30:59 -0500 Received: by interlock.amoco.com (Protected-side Proxy Mail Agent-2); Mon, 10 Apr 1995 15:30:59 -0500 Received: by interlock.amoco.com (Protected-side Proxy Mail Agent-1); Mon, 10 Apr 1995 15:30:59 -0500 From: jwagener@amoco.com X-Openmail-Hops: 1 Date: Mon, 10 Apr 95 15:30:11 -0500 Subject: US input for CD ballot processing in Tokyo To: mellis@vax.ox.ac.uk Cc: sc22wg5@dkuug.dk X-Charset: ASCII X-Char-Esc: 29 Item Subject: Message text Miles, here are the US comments relative to submitting 95-007 for CD ballot. As per our agreement in Houston, the X3J3 TAG has held an informal letter ballot on submitting 95-007 for CD ballot, for the purposes of providing every US member of X3J3 an opportunity to submit, in writing, his or her comments. The attached are those comments. These comments do not represent an official position of the US (the ballot results produced no such position), nor should any of these comments be interpreted as having US support. As you will recall, because of the tightness of the schedule, we simply agreed to collect the comments and present them at the WG5 meeting as an official US contribution of (hopefully useful) input to, not any sort of official US position on, the CD ballot processing at the Tokyo meeting. My apologies for the formatting glitches of the attached - I shall bring more readable copies with me to the meeting next week. Please note that two of the comments depend heavily on references to other papers, namely X3J3/95-098 and X3J3/95-103. Therefore please consider these two papers as part of these comments. I believe that X3J3/95-098 is the same as WG5 paper N1095 (or thereabouts); I'm not sure whether X3J3/95-103 has a WG5 N number or not. In any event I will also bring copies of these two papers with me to the meeting so that WG5 will have a complete set of US comments to consider in processing the CD. Thanks very much. Looking forward to seeing you next week. Jerry Wagener acting X3J3 international representative PS - by the way, Tom Lahey will be head of the US delegation in Tokyo. -jlw ....................................................................... FROM: jwagener/unix_in////////HPMEXT1/jwagener#a#hou#f#amoco#f#com@houeosm4 TO: ustag-fortran@ncsa.uiuc.edu CC: Miles.Ellis@educational-technology-resources-center.oxford.ac.uk ....................................................................... Item Subject: Results of the TAG ballot on 95-007 Received: from hou.amoco.com (earth) by houeosm4 with SMTP (1.37.109.16/16.2) id AA077025120; Fri, 7 Apr 1995 17:52:00 -0500 Received: from netserv2 by hou.amoco.com (4.1/SMI-4.1) id AA10267; Fri, 7 Apr 95 17:51:38 CDT Received: from interlock.amoco.com (portal.trc.amoco.com) by netserv2 (4.1/SMI-4.0) id AA00354; Fri, 7 Apr 95 17:51:49 CDT Received: from newton.ncsa.uiuc.edu by portal.amoco.com with SMTP id AA17860 (InterLock SMTP Gateway 3.0 for ); Fri, 7 Apr 1995 17:51:02 -0500 Message-Id: <199504072251.AA17860@portal.amoco.com> Received: from interlock.amoco.com by newton.ncsa.uiuc.edu with SMTP id AA16642 (5.65a/IDA-1.4.2 for jwagener@amoco.com); Fri, 7 Apr 95 17:32:08 -0500 Received: by interlock.amoco.com id AA17915 (InterLock SMTP Gateway 3.0 for ustag-fortran@ncsa.uiuc.edu); Fri, 7 Apr 1995 17:36:59 -0500 Received: by interlock.amoco.com (Protected-side Proxy Mail Agent-3); Fri, 7 Apr 1995 17:36:59 -0500 Received: by interlock.amoco.com (Protected-side Proxy Mail Agent-2); Fri, 7 Apr 1995 17:36:59 -0500 Received: by interlock.amoco.com (Protected-side Proxy Mail Agent-1); Fri, 7 Apr 1995 17:36:59 -0500 From: jwagener@hou.amoco.com X-Openmail-Hops: 1 Date: Fri, 7 Apr 95 17:36:35 -0500 Subject: Results of the TAG ballot on 95-007 To: ustag-fortran@ncsa.uiuc.edu Cc: Miles.Ellis@educational-technology-resources-center.oxford.ac.uk ....................................................................... Item Subject: Results of the TAG ballot on 95-007 Adams comments 1. If the limited proposal for ENABLE that is proposed is added to the requirements for this time, my vote would change to YES. Condition handling has been a requirement and a proposal of some kind for a good many years. It is more important to have in the standard than some other facilities that have been included. Fortran may be set aside because of this lack. That is unfortunate since Fortran is making a quite good come-back. 2. While I would not vote NO because of this, I believe that more time must be spent on the "document integrity and consistency". Bleikamp comments Foreword: xiii:17 Delete reference to 1.5.2. xiv:2 change "90" to "95" xiv:10 delete "tremendous", substitute something less pretentious xiv:17 change "declare a nullified" to "nullify a" xiv:39 Why are All the words if section 3's title capitalized here, but not in the actual title in section 3? xv:26 there are too many "and"s in this sentence xvi:3 put "arithmetic IF" in the obsolescent font xvi:8 after "file positioning" add "(REWIND, BACKSPACE)" xvi:10 after "I/O", add the word "formatting", twice xvi:21-22 This sentence is awkward xvi:31 internal procedures and modules are not new additions in F95, this needs to be reworded or deleted. xvii:2 change "such" to "the" (too many "such"s in this sentence) Section 1 3:16 after "deleted features", add "listed in 1.5.1" (to be consistent with lines 43-44 on the same page) Section 2 13:5 replace "such accessibility" by "access" 18:11 I suggest inserting "the use of" before "optional arguments" 30:35-36 I think "redefines" should be singular, since we used "define" earlier. Section 9 138:30 A comment in the last letter ballot on the 006 pointed out that the text we added to allow a STATUS="old" for currently OPENed files, including files with a status of SCRATCH, is in conflict with this statement, since we require a filename when STATUS=old is specified, but the already connected file with status scratch MUST be an unnamed file (there is no other way to OPEN a scratch file). To resolve this, I propose the following edits: 138:30 -- delete "OLD, "from the list, and add this sentence after 138:31 If the STATUS= specifier has the value OLD, the FILE= specifier shall be present unless the unit is currently connected and the file connected to the unit exists. 140:20-29 In this paragraph, references to "character constants" should be replaced with "character values" (at least 3 times), or some other phrase. These values are not always in the form of the BNF thingee we call a character constant (undelimited, ...). Also, we are "writing" values, not constants. (this comment was made by a reviewer of the last 006 letter ballot) 146:18 In the Note, change "the descriptor" to "a descriptor" Section 10 These edits to chapter 10 are appropriate IF WALT's namelist rewrite is NOT adopted. If Walt's rewrite is adopted, please consider these edits individually to see if they are still appropriate. 173:6+ Add a NOTE after list item (3), which says: "Although a slash encountered in an input record is referred to as a separator, it actually causes termination of list-directed and namelist I/O input statements, and does not actually separate two values." 173:35 Change "Character constants" to "Character sequences". (non-delimited character sequences are NOT in the form of a constant). 173:38 change "constant" to "character sequence" TWICE. 173:40 change "constants" to "sequences". 173:41+ For the rest of this subsection, make similar changes wherever word "constant" is used for a character sequence in an input record. 175:24 Change "constants" to "sequences" 175:28-29 Change "constants" to "sequences" and change "within a constant" to "within a constant or sequence" TWICE. 175:43 Change "Character constants" to "Character sequences" 176:4 Change "constant" to "sequence" 176:6,9 Change "constant" to "sequence" 176:15 Change "constants" to "sequences" 177:1+ Add this note after list item (5) "A slash encountered in a namelist input record causes the input statement to terminate. A slash may not be used to separate two values in a namelist input statement." 177:25 Change "logical and integer" to "logical, integer, and character" 178:7 change "ignored" to "ignored, and need not follow the rules for namelist input values." 178:22-29 Change "character constant" and similar phrases to use "character sequence" or possibly "delimited character sequence". THIS IS NOT A REQUIRED CHANGE. unlike list-directed I/O, namelist input character values MUST be quote or apostrophe delimited, so the input form is of the form of a character constant (except for continuation rules). 179:44 Change "constants" to "values". 180:1 change "character constants" to "character values" (or possibly sequences) 180:5-6 change "character constants" to "character values" and also change "within a constant" to "within a constant or character value" TWICE. In all of section 10, when discussing "logical constants" in the context of an input/output record, replace "constant" with "value" or something else appropriate. A simple "L" is not a logical constant in Fortran, but it is allowed in I/O records. 180:23 change "constants" to "values". 180:30 change "constant" to "value". 180:34 change "constant" to "value". 180:35 change "constants" to "values". 180:38 change "constants" to "values". 181:11 change "constants" to "values". Section 12 217:18-21 Replace this paragraph with text such as this (from J. Reid) "In a reference to the intrinsic subroutine MVBITS, the actual arguments corresponding to the TO and FROM dummy arguments may be the same variable. Apart from this, the actual arguments in a reference to an elemental subroutine must satisfy the restrictions of 12.4.1.6." Maine comments Although 95-007 still needs work (see X3J3/95-103), I believe that it is in good enough shape to be adequate for a CD ballot. I consider the items numbered 2, 4, 7, 8, 24, 42, 46, 53, and 54 in X3J3/95-103 to be significant technical issues. I consider the items numbered 3, 28, 29, and 59 in X3J3/95-103 to be significant organizational problems (items 3, 28 and 29 are essentially all one problem). These significant technical and organizational problems should ideally be fixed before the CD ballot, but could acceptably be fixed afterwards. The remaining items in paper X3J3/95-103 are of less significance; many are things like awkward wording that read poorly, but do not raise technical issues. Martin comments On the whole it looks very good. My compliments to the editors. I did notice a few problems: Introduction [xiii:17] delete "and 1.5.2" [xiii:31-41] The description of FORALL is inadequate. We had to eliminate the title "Element Array Assignment" because it implies that the construct only works on array elements. Actually, it can apply to array sections (else why could it contain a nested WHERE construct?) and pointer assignments. This description fails to mention these possibilities. In particular lines 34 and 41 need to be changed. [xiv:17] item (b) should begin with "a" [parallel construction with item (a)] [xiv:39-xvi:30] Only the first word of the titles should be capitalized. [xv:27] allocation and array deallocations -> allocation and deallocation [They could both be plural, but singular reads better, particularly when the redundant "array" is removed.] [xv:28-30] Automatic deallocation does not apply to user-allocated variables in general - only to user-allocated allocatable arrays. There are two instances of "variables" that need to be changed. [xv:42] Same problem as on page xiii. [xv:45] change to, "CPU_TIME, NULL, and extensions to MAXLOC and MINLOC with corresponding changes to other similar intrinsics." [See page 3, line 29.] [xvi:3] "arithmetic IF" should be in small font. [xvi:30-31] delete parenthetic phrase Section 2 [14:18] The last line in the note is correct, but difficult to read. It would be better as, "The scoping unit of a module does not include any module subprograms." Section 3 [25:31+] add "ELSE WHERE" or Note 7.50 [112:10] must be changed Section 4 [30:36] redefines -> redefine [46:27] The Note number is missing; it should be 21. Section 5 [47:41 - 48:33] These constraints should be reordered to reflect the order of the syntax rules, for example [47:42-43] should appear much further along in the list. [52:27] Delete "and derived-type definitions" [Entities includes type definitions, so this text is confusing; see glossary.] [56:11-18] This text is awkward. Suggested replacement: "An object with the SAVE attribute, declared in the scoping unit of a subprogram, retains its association status, allocation status, definition status, and value after execution of a RETURN or END statement. The object is shared by all instances (12.5.2.4) of the subprogram. Such an object is called a <>. An object with the SAVE attribute, declared in the scoping unit of a module, retains its association status, allocation status, definition status, and value when a RETURN or END statement is executed in a procedure that accesses the module via a USE statement." [57:36] A -> B [Optional arguments should be last or the user is forced to use the keyword form.] [60:37-61:42] These rules and constraints are in a peculiar order. The following is a logical order: R533 R534 R538 R539 R540 61:26-27 61:32-36 61:17 61:40-42 61:12-15 61:37-39 R535 R537 R536 61:18-20 61:30-31 61:28-29 61:21-25 [62:26+] add TYPE(NODE), POINTER :: HEAD_OF_LIST [62:30+] add DATA HEAD_OF_LIST / NULL( ) / [62:38] add following "Note 4.20." The pointer HEAD_OF_LIST is declared using the derived type NODE from Note 4.26; it is initially disassociated. [An example might be useful here.] [70:4-7] delete paragraph [There are several things wrong with this para- graph. COMMON does not allow access to objects; it allows access to storage. This is the Fortran 95 standard so it is not relevant that extensions were made to Fortran 90. [70:10-11] Replace complete sentence with, "For example, this allows a single common block to contain both numeric and character storage units. Section 7 [110:35, 37, 39] These lines should be indented. See F90 standard [93:1-5] [110:39] delete last "..." [111:4] There seems to be an extra tab. [111:25] delete parenthetical phrase - not needed in light of [6:16] (1.6.5) [111:33] delete parenthetical phrase - not needed in light of [6:16] (1.6.5) [116:30] remove blank after = so numbers line up Rolison comments This is a VERY difficult ballot for me but I find my answer must be: NO, I do not approve of submitting 95-007 for CD ballot, with the following reasons and comments. I have had a very difficult time trying to decide on how to vote on this ballot. On the one hand, I've felt that I should be a "team player" and vote Yes because of all the work both X3J3 and WG5 have done on the standard in the last couple of years (including the interpretation processing). On the other hand, I find that too many of the interpretations have responses that were constructed in haste and/or (as far as I'm concerned) are just plain wrong (the primary case that comes to mind is 125). I feel that we're repeating old history, that we're right back to April, 1991, when the hue and cry was "Sure it's wrong - but let's just get it out and fix it in interpretations." Nearly 200 interpretations later we're STILL trying to fix it. In the end, I must vote my conscience which is No. I feel there are just too many holes remaining (again especially the glaring problems with 125) and that if we KNOW the standard is wrong, we should fix it plain and simple. If we were to read about a car manufacturer, for instance, that KNEW that a fuel system was not designed properly and could lead to explosions but we continued to build the car anyway, would we not richly deserve the vilification the media and public would heap upon us? Is releasing a programming standard that will affect tens of thousands of programmers for decades to come (and knowing that it has serious flaws) really any different? If major interpretation responses such as those to 125 get corrected, I would consider changing my vote to Yes. Wagener comments It is with the most extreme reluctance that I must, in good conscience, vote no on submitting a document for CD ballot that does not contain some support for handling floating point exceptions. In these turbulent times, the good ship Fortran needs a firm anchor to weather current storms and emerge in shape to triumph across the high seas. That anchor, in my opinion, is premier support for numerical computation, which will be lost without at least some modest way of handling certain floating point exceptions. More detailed reasons, and viable options, have appeared in various papers I've written on this topic over the last five months, most recently X3J3/95-098 and WG5 document (approximately) N1095. Zongaro comments Introduction [xv:42] Change "is" to "may be". FORALL assignment can apply to array sections and character substrings. [xvi:30-31] Delete the parenthetical expression that begins "(especially". These features are no longer new. Section 5 [50:60-62] I'd like to argue that NULL() should not be allowed to appear as a . The rationale behind allowing this was to improve consistency, by allowing pointer initialisation to occur in DATA statements. For example, both of the DATA statements below would be conforming in Fortran 95, with this change. integer, pointer :: p type dt integer, pointer :: p end type dt type (dt) :: s data s/dt(null())/ data p/null()/ If NULL() was not allowed to appear as a , only the first DATA statement would be conforming. However, with the following small change to the declarations, integer, pointer :: p(:) type dt integer, pointer :: p(:) end type dt the first DATA statement is valid, but the second is not. The addition of NULL() as a does not deal with the case in which the pointer to be initialised is not a scalar. Since this addition did not meet its stated objective, I'd like to see the feature removed with the following edits: [60:26] Delete ", and pointers may be initially nullified". [61:3] Delete the line "or NULL()" [61:36] Before "or", insert "a pointer, " [62:16] Delete entire sentence. [62:20-21] Delete entire sentence. [89:37] Delete table entry. [50:37-40] Both constraints should be in obsolete font. Section 7 [89:35] "argument" should be "component" Section 12 [215:24] Delete "or SIZE=". The SIZE= specifier only applies when ADVANCE= is specified, ADVANCE= is not allowed with an internal file unit specifier, while PURE does not allow external file units or *. Section 13 [253:42-254:2] HPF defines the result of MAXLOC(ARRAY, DIM[, MASK]) to be a scalar if ARRAY has rank one. 95-007 defines it to be equal to MAXLOC(ARRAY[, MASK]), which is a rank one array of size one. If DIM was added to the definition of MAXLOC for compatibility with HPF, the definitions should be consistent. In addition, the definition of MAXLOC(ARRAY, DIM[, MASK]) when the rank of ARRAY is greater than one, specifies that each element of the result is equal to value which is a rank one array of size one, rather than a scalar. [256:30-34] Comments similar to those for MAXLOC apply to MINLOC. Section 14 [285:20] If NULL() is allowed to appear as a , after "(5.1)" add "or a DATA statement (5.2.10)"