From maine@altair.dfrc.nasa.gov Wed Feb 14 00:23:23 1996 Received: from altair.dfrc.nasa.gov (altair.dfrc.nasa.gov [130.134.34.72]) by dkuug.dk (8.6.12/8.6.12) with SMTP id AAA12950 for ; Wed, 14 Feb 1996 00:23:15 +0100 Received: by altair.dfrc.nasa.gov (5.0/SMI-SVR4) id AA01376; Tue, 13 Feb 1996 15:23:54 +0800 Date: Tue, 13 Feb 1996 15:23:54 +0800 Message-Id: <9602132323.AA01376@altair.dfrc.nasa.gov> From: Richard Maine To: sc22wg5@dkuug.dk Subject: Response to editorial comments on N1166 content-length: 4850 The following paper was brought up at the X3J3 meeting as X3J3/96-038 to see if there were any objections to the responses. No such objections were voiced there, so I'm sending it out. UK substantive points 5&6 were addressed separately by X3J3 in paper X3J3/96-050. In short summary, John Reid's suggestions are accepted, with corresponding changes to the notes so that they agree with the revised text. I'll include the exact edits in my compendium of changes incorporated. ------------------------ Miles received individual comments from Alla Gorelik, David Muxworthy, and myself on N1166, also known as X3J3/95-007R2, the f95 draft produced after the San Diego meeting. My own comments, many of them compiled from email discussions, are in paper X3J3/96-030. All of them have been incorporated into the current draft, which is not yet released. The following are responses to Alla Gorelik's comments: 1. General comment on Chapter 13. The misprints that Alla noted have been corrected. The change suggested to the heading syntax for optional arguments is not accepted. The syntax with multiple versions of the headings implies semantics that is different from that of optional arguments; this is intended for the few places where that syntax is currently used, but is not appropriate elsewhere. The syntax with nested brackets is too complicated for a section heading, yet still fails to completely account for such things as keyword argument syntax. This issue was previously raised. After extensive discussion, the approach decided on was to use the current syntax and to add material to section 13.3 explaining the use of the syntax in this context. N1166 reflects that decision. The comment does not appear to bring up any new aspects that were not considered in making that decision. 2. Rank is an attribute. Comment accepted. All 3 sentences in question will be edited to read "It is a scalar variable that has the type and type parameters..., and this type shall be integer type; it has no other attributes." 3. Uniformity in whether section 5.2 repeats constraints from section 5.1. This goes beyond the scope of simple editorial changes. In some cases, there might be subtle technical distinctions that are not editorial matters. There are also several other apparent inconsistencies in how material in section 5 is organized and presented. The section would probably benefit from a substantial reorganization. However, this degree of change, even to the extent that it is purely editorial, seems too large for this stage in the process. 4. "i" -> "I" on 316:12. Comment accepted. 5. Definition of "reference" in 2.5.5 versus 73:3 in section 6. This seems to be suggesting adding an introductory sentence in 2.5.5 reading something like The term "reference" is used in three ways in this standard. This closely follows the form of section 2.5.2 as suggested. I don't see this change as adding to the clarity, however. The three uses of "reference" are compatable in that they can always be disambiguated based on the subject (a data object, a procedure, or a module). Note that this is not 100% true of the term "keyword"; for example, a mention of "the keyword END" could concievably be ambiguous in a subroutine with a dummy argument named END. 6. Question about note 13.8. This appears to be a technical interpretation question for WG5, rather than an editorial question for the editor. However, I'll venture an answer. An actual array argument can correspond to a scalar dummy argument only for elemental procedures. CPU_TIME is not an elemental procedure. The note suggests that a processor could concievably extend the CPU_TIME intrinsic by adding a version with a vector argument. However, a program that made use of such an extension would be non-conforming. See 2:37-38 "A standard-conforming program shall not use nonstandard intrinsic procedures that have been added by the processor." I would interpret this as also applying to nonstandard additional specific versions of standard generic intrinsics. The following are responses to David Muxworthy's comments: The typos on page 305 pointed out by John Reid have been fixed. The use of small caps in "FORTRAN 66" and "FORTRAN 77" has been made consistent as requested, except in the table of contents entry for section 1.5.2, where I was unable to convince Frame to do it. The other typos communicated to me by email have been fixed and are included in my comments. The UK substantive points 5 & 6 are technical questions being considered separately from this paper. ------------------------ -- Richard Maine maine@altair.dfrc.nasa.gov