J3/00-309 Date: 13 Oct 2000 To: J3 From: Richard Maine Subject: Edits incorporated in 00-007R3 This paper describes the changes in J3/00-007R3 relative to the previous f2k draft, J3/00-007R2. All page/line references are to J3/00-007R2 unless otherwise noted. Ths change bars in 00-007r3 are relative to 00-007R2. This includes edits from papers (all 00-) 233r2, 236r1, 237r2, 238r1, 239r1, 241r1, 242r1, 243r1, 244r1, 246r1, 248r2, 250r3, 252r1, 256r2, 258, 263r1, 265r2, 266r1, 267r2, 270, 275, 276r2, 277r2, 278, 280, 281r1, 282r1, 283, 284, 285r2, 286, 287r2, 288r2, 290r1, 291r1, 293, 294r2, 296r1, 297r1, 298r1 misc edits not in papers [56:1] fix spelling of "inaccessible" Per floor vote, resolved issue 225 by removing all italics in Annex A except for those few (3 cases) that are bnf terms. Correspondingly removed the senetnce in the intro to Annex A that had explained the italics. [140:29] Fixed obviously incorrect xref, as pointed out by Kurt. The R603 should be R621. This appears to have been a corrupted xref entry in Frame's tables, because it kept re-breaking on every index/xref regeneration until I deleted the xref marker from the real R603 and then re-entered the xref. An alternate fix would have been to just delete the duplicates of R618 and R621 on pg 140. We don't normally (ever elsewhere?) duplicate syntax rules defined previously - though chapter 2 does duplicate several defined subsequently. But for now, I just fixed it. P.S. This is bad in f95 also - should probably be an interp/defect. paper 00-233r2, with the following changes I assume the edit at [43:28] is meant to be [43:28+]. I'd have probably made 4.5.1.5(1/2) (dtio bindings) just an extra para in 4.5.1.5 (type bound procs) instead of a subsection all its own. This is, after all, a particular kind of type-bound procedure, rather that something different. The words certainly say so, although this sectioning implies otherwise. And 4.5.1.5 isn't very long, even with this added. This change wasn't clearly enough needed for me to just do or to really merit an unresolved issue. So I just mention it here as a minor suggestion. I entered the edit as specified. 2nd sentence of 48:30+ sounded like 9.5.4.4.3 described only one particular one of the dtio bindings instead of all of them. Changed "a binding for a particular" -> "the binding for each". Omitted last comma in last sentence of para at 48:30+; and the first comma in the note. The edit at [53:38+] had two contradictory intructions on where to put it, both being at least plausible. It said to put it at [53:38+] after note 4.44. After note 4.44 would have been [54:28+]. I put it after note 4.44, after changing my mind at least once. The first para of 4.5.3.2 says "declared in a type" twice. The new last para says "declared in a type definition" in one case of exactly the same context and then "declared in a type" for the cond case. Its arguable which is better, but I see no reason for them to be different. After flipping several coins, I included the "definition" in all 4 places, as "in a type" doesn't seem to really make sense. (Perhaps "for a type" would be an alternative). In fact, while I'm at it, I made them all "specified in a type definition". Too many "defines" in "defined in a type definition", and I think we normally use "specified" for this kind of thing anyway. Added a comma in the edit at [53:38+] (or [54:28+]. [189:26-27] Also changed "any" -> "a". And I'm not quite sure that it's right to say that a dtio procedure is "accessible by a dtio-generic-spec", but I don't have better words handy (and have spent a lot of time on this paper already), so I'll just enter it as is. Perhaps "made accessible", but that doesn't seem perfect either. [190:25] Added "derived" before types. Not strictly needed, but we do use "derived types" all over when talking about these. Suppose we shouldn't give the impression that they ever apply to intrinsic types. [191:32+] I don't really think the "i.e." part here belongs as normative text. Either say it one way or the other, possibly with an xref, but this isn't the place to define polymorphism. But I left it alone anyway. [246:47+] I assume the 9.5.4.4.2 should be 9.5.4.4.3. Fixed. [251:13+] I don't think it makes sense to xref 12.3.2.1 from a subsection of itself. The whole point of the subsection is to elaborate on part of the section. So I omitted the xref. paper 00-236r1 as is paper 00-237r2 as is paper 00-238r1 as is paper 00-239r1, with the following changes Split the first sentence of the Annex C addition into two for better sentence parsing. As noted on the floor, the code added to Annex C is not in a note. paper 00-241r1 as is (including the edit to 120:26 added on the floor) paper 00-242r1 as is paper 00-243r1 passed, but its edits are all in a section deleted by the subsequently passed 00-266r1, so they are moot. paper 00-244r1 was not passed, but was editorial items that the editor was requested to consider. [48:32] "PASS_OBJ attribute" entered instead (to match other cases). And "passed object dummy argument" was already indexed here in 00-007r2 (or earlier). Other cases of "double colon" hyphenated at 58:26, 65:39,68:2 (but not in a few places where it wasn used other than as a modifier). [55:15] Duplicates some other paper. [77:11] And another comma [136:19] Added the comma, but editor thinks the "then" helps clarity here. [343:15] Same change on [343:13] [404:25+] Duplicates some other paper. paper 00-246r1 as is paper 00-248r2 with the following changes Hyphenated "processor-dependent". paper 00-250r3 with the following changes The insertion at [49:10+] is in the middle of an area modified by a separate paper in such a way that the specified insertion point is ambiguous. I choose a point that seemed plausible. But see unrtesolved issue 284 for more. While editing the Annex C example, I also deleted some of the blank lines between every line at the end of the example. It made the code awfully spread out, and I thought harder to read. paper 00-252r1 as is paper 00-256r2 as is paper 00-258 as is paper 00-263r1 with the following changes. Add comma after "Therefore" in the note. Change "interoperates with" -> "is interoperable with" paper 00-265r2 with the following changes. "indicates if" -> "indicates whether" "Function" -> "function" Add scalar requirement to both arguments. Omit the word "section" before 6.3.2.3. I presume the example is intended to go in a note. paper 00-266r1 with the following changes. Paper 266r0 had a two sentence introduction to the descriptions of the module procedures. Those sentences got dropped in the process of recasting the procedures as intrinsics in 00-266r1. On of the dropped sentences had content that needs to be said somewhere - namely "The meaning, interpretation, and means of providing command arguments are processor dependent." We need to say something about the new intrinsics in the early subsections of 13 anyway (the confusingly organized subsections). Broadened the title of 13.12.4 and included the new subroutines there. Added new section 13.11a for the new function. Also added the one-line descriptions to the edits on pg 289. And moved the entry for the function out of the section that specifically says it is subroutines. For adding as intinsics, make the classes "Inquiry function" and "Subroutine". Don't need to say "pure" in this context. In the description of STATUS in GET_COMMAND "argument"->"command" twice. (Description was copied from GET_COMMAND_ARGUMENT without this needed change). paper 00-267r2 with the following changes "can" -> "may" The last edit done as normative text merged with the preceding para instead of as a note. Also moved the C standard xref up by a sentence. "processor dependent" not hyphenated in the two uses here. Omit the "section" before 7.19.2. paper 00-270, with the following changes In note 4.44a ", and" -> "; it is interpreted" In note 4.44a "so interpreted" -> "interpreted as a generic ". paper 00-275, with the following changes "i/o" -> "input/output" hyphenate one case of "derived-type" in 4.5.3a. Split the first sentences of 4.5.3a and 4.5.3b into two clauses to avoid confusing modifier placement. In the 55:3-6 edit, "names"->"keywords" 55:25-27 "components" -> "component" paper 00-276r2, with the following changes "when" -> "if" in the first edit. Also deleted issue 18, as suggested by the title, but not explicitly mentioned in the edits. paper 00-277r2, with the following changes My review of much of the material added by this paper was pretty hasty, which may mean I missed a lot. Made what seemed like reasonable placement several of the edits relative to edits from paper 00-233r2 in the same places. [43:28+] Added "A" at the start of the first constraint and also added "the name of" before "a" on the first line of it. Reworded 2nd sentence of first constraint in [43:28+] so that nonoptional modifies argument instead of variable. We don't refer to optional variables. Also added some commas. [50:44+] 2nd para. Deleted the comma and added one elsewhere. [52:40] No hyphen on "nonfinal". Seems to me like the 3 new subsections of 4.5, all related to finalization, might better be moved one level lower as sub-subsections of one on finalization. But I didn't do so. 4.5.7b 2nd and 6th paras, and note 4.49b. Added a comma. 4.5.7b Omitted "the" before 3 cases of bnf terms. 4.5.7c 1st para. "no objects ... are finalized" -> "objects ... are not finalized" Singularized the gloosary entry for "final subroutine". paper 00-278 with the following changes. First edit omitted per floor discussion. paper 00-280 as is paper 00-281r1 with the following changes. [68:2+] I put the first new constraint at [67:40+] instead of just adding it to the end of the constraints. Added the second one to the end as specified. I don't understand why the direction to use "type parameter value" as opposed to "". The bnf term is used in all the other constraints here. And the bnf term seems far more explicit than having to assume that "type parameter value" is referring to . Not that this inference is hard to make, but if the bnf is used, no inference at all is necessary. One might also question whether * is a "value"; I could almost imagine someone using the term "value" to indicate the possibilities other than ":" or "*". Again, the bnf term is explicit and leaves no such question. But subgroup explicitly recommended this change, and it was passed, so I'm doing it as passed. Still, I wonder. Its not a big enough question to merit an unresolved issue. Along that line, this section seems inconsistent in using "*" versus spelling out "asterisk". It probably doesn't really matter; just seems strange. I did nothing about this other than to note it here. Ignored item (2) of the edits at [68:2+] and [68:11-34] because it is part of the feature deleted by paper 00-266r1, which had an overlapping edit here. Lower-cased the "To" in [68:2+]. It doesn't begin a sentence and didn't match the capitalization style of the other items. Added an "for a" to help parsing of the last constraint added at [68:2+]. Yes, I know this text was just moved, but it still helps. Changed "as" back to "in" in the item about the ALLOCATE statement in [68:11-34]. Admitedly, the "in" is a bit vague and might merit improvement. But "as" is just plain wrong - an asterisk is not valid as a ; it can be part of a , but is not a complete . "Corresponding" -> "associated" in the item about the ALLOCATE statement in [68:11-34]. We have a perfectly good, well-defined term in "associated". In fact, it was used in the immediately preceding item. Why confuse matters by using a vague term like "corresponding" to make people wonder whether some other correspondence is meant. For example, someone might think that this implied a correspondence between the order of the and that of the actual arguments. "the" -> "a" in the last item at [68:11-34]. This edit removed the "in an external function" that profided the referent for the former "the". Without such a referent, it needs the indefinite form. But the cases after the first remain "the" because the first case provides the referent. "declare" -> "specify" in the last item at [68:11-34]. We tend to use "declare" only in the context of the declaration of a named entity - not in the context of declaring a parameter. The text this replaces used the term "specify". I am not sure whether or not it was intended to delete the former note 5.7. The material of the note seemed largely orthogonal to the edit. The instructions did say to replace a range of lines that included the note, so I did so. I'm not entirely sure whether this was the intent. The note was admitedly...peculiar...but it was there to address a point that had confused some people. Omitted the "if it is a pointer" qualification from the insertion at [244:28-29]. The sentence didn't parse sensibly at all as was. A comma after this phrase would have helped slightly, but this is already in the middle of a long comma-delimited list so the result would still be awfully hard to read. The phrase is superfluous in this context anyway; if the argument is not a pointer, then it also isn't a procedure pointer; there is no need to make the extra condition, particularly when it is so hard to read. paper 00-282r1 with the following changes. I believe I got all the changes between R0 and R1, but its worth checking me. We approved two different versions of the glossary entry for "effective item". One as part of paper 00-293 (which said to use the words from 00-261 as is) and one as part of paper 00-283r1. I used the words from 00-261 because I had already entered them before noticing the duplication and because the words from 00-261 seem more succinct anyway. Added an "is" in the definition of pure procedure. [367:19+] Add "(X)" after the intrinsic name, following the style of all the other entries here. [194:9-10] Factored "the" out of the list. (I.e. put only one at the beginning instead of one for each item). paper 00-283 with the following changes. Deleted issue 257, although the paper neglected to explicitly say to do so. line number 342+ should have been 42+. Add "a" after "Such" in the note. Fix typo of "bewtween". Fix the list syntax of (5)-(7) on pg 392 while in the area. After that list syntax fix, the new note that the paper proposed to put after item (6) needs to go after the end of the list (because you don't want a note in the middle of a sentence). And the former note 16.14 is moved to be a second para of this new note. And change "reference" to "referenced" in it just like the other 2 places. paper 00-284 with the following changes. Added a comma before "even though". paper 00-285r2 with the following changes. No intentional changes, but my notes on the changes between r1 and r2 were a little abbreviated. I think I got them right. paper 00-286 with the following changes. As mentioned on the floor, one "may"->"might" and two "which"->"that" Deleted a comma. Added "specification" after attribute. (A name appears in the attribute specification - not in the attribute). Deleted "same as the" as adding nothing. The name just *is* the name that apears in the extends attribute specification. paper 00-287r2 with the following changes. Retitled the new section in c13 ISO_IO_MODE because all the other section titles at the same level were actual names instead of descriptions. The paper mentions issue 30 in its title, but does not specifically say to delete issue 30. I am assumimg this to be intentional, so I did not delete the issue. The paper does appear to address material related to issue 30, but presumably not everything. (And indeed some of the specific words mentioned by issue 30 remain in 10.7.4.). No comma after "in which case". A couple of problems with the edit at 339:33. All derived types are named, so its a bit silly to use the modifier there. And the sentence is a bit specific anyway. We don't need to elaborate here that the module provides only constants and types as though that had any particular consequence. I simplified it to address only what does seem of consequence and to tie to the module name - that the module "provides public entities relating to the Fortran environment". I added a token sentence in 13.7.2 just so that the section intro didn't say there were two things and then present three. I also removed "values" from the title of section 13.7.2 so that the title still applied to all of its subsections (the new subsection defines a type instead of a value). The addition at 130:22+ failed to explicitly state the requirement that the module define ISO_IO_MODE. Just putting code for a derived type definition here doesn't make such a requirement. You have to say it. I added a lead-in phrase "The processor shall provide a derived type defined as". I then moved what was the first sentence of the section to after the derived type definition; it seemed to fit better after the type is defined rather than as a lead-in. Also changed "mode" to "formatting modes" in this sentence. There are multiple modes involved rather than just one (and other sentences in this same sentence use the plural "modes" in referring to what is in variables of this type). Also, it seemed worth using some form of the word "format" somewhere in this section. All of these modes are, after all, pertinent only to formatting (which is presumably why io_mode is passed only to the procedures for formatted i/o). Removed yet another incorrect use of the undefined phrase "child data transfer procedure". And then rewrote that whole sentence anyway to make exlicit that it was talking about a variable of the type. We didn't have a bulleted paragraph style defined in the Frame template, and it's quite a nuisance to add new paragraph styles, so I reused the style of the argument descriptions in the intrinsics. Trivially changed the wording of each component to fit this style. (Nothing wrong with the style of the paper in this regard - its just that Frame is such a pain on the matter, so the editor tries to use existing para templates as much as possible). Deleted the phrase "currently in effect" from each of the components. The lead-in says these are "current" modes; repeating the phrase for each one doesn't seem to add anything. (If we want "currently in effect" instead of just "current" - not that I see a difference - we could still say it just once instead of 6 times). "or" instead of "and" in all the component value descriptions. The component has only one of the values, not all of them. Added "that" twice to the last sentence. paper 00-288r2 with the following changes. "when" -> "if" in the first edit (unless we want to imply that this might somehow change during execution of the statement). "the POS=" -> "this" in the second edit. Shorter and just as clear here. Left "the ID=" alone in the third edit because it seemed to fit better in the context there. paper 00-290r1 with the following changes. Hyphenate "derived-type" 3 times. Omit the word "section". paper 00-291r1 with the following changes. Everything marked as bold in the paper was entered as italic. (Probably just confusion about the markup convention). paper 00-293, with the following changes Add "-name" to the edit on 115:42. paper 00-294r2 with the following changes. "data transfer" -> "input/output" before "procedures". One could call these "data transfer procedures", but that's not the terminology that we use. paper 00-296r1 with the following changes. Added a "the" in the para at [104:29+] paper 00-297r1 with the following changes. Lower case for "character" here; its not used as a keyword. The term "character assignment rules" doesn't appear in the standard in quite that form and it neglects to include the word "intrinsic" which seems pretty important. I used here the same kind of phrasing that we've used elsewhere - "..do so in accordance with the rules of intrinsic assignment". paper 00-298r1 as is