J3/01-190 Date: 25 Apr 2001 To: J3 From: Richard Maine Subject: Edits incorporated in 01-007R1 This paper describes the changes in J3/01-007R1 relative to the previous f2k draft, J3/01-007. All page/line references are to J3/01-007 unless otherwise noted. The change bars in 01-007r1 are relative to 01-007. This includes edits from papers (all 01-) 103r2, 104r1, 105r1, 108r3, 109r3, 110r2, 111r3, 112, 113r2, 114r2, 115r1, 116r3, 120r2, 122r1, 123r2, 124r1, 125r1, 126r1, 127, 130r1, 132r2, 133, 139r1, 142r1, 143r1, 147r1, 150r1, 162r2, 163r1, 164, 167r2, 168r1, 169r2, 170r1, 171r1, 173r1, 174, 175, 176r1, 177r1, 178r1, 181, 182r2, 183r1, 185r1, 186r1 misc typos and fixes not in papers 67:32 "To" -> "to" 221:40 "c the hange the" -> "change the" 222:4 "blankk" -> "blank" 281:19 "Standsard" -> "Standard" 249:13 "decribed" -> "described" 383:30 "MATRIX ERROR" -> "MATRIX_ERROR" 187:12,13 "imediately" -> "immediately" * 2 187:19 "visa versa" -> "vice-versa" [418:28-29] "to use" -> "using". The sentence formerly read, eliding irrelevant parts, "by defining...and to use". Also deleted the "say FLOAT". It is spurious and oddly phrased (I wonder how that usage of "say" translates). paper 01-103r2, parts 1-3 as is paper 01-104r1 as is (This paper just fixes typos made in entering previously passed papers. No vote was taken or needed). paper 01-105r1 with the following changes The minutes and my notes say there was to be a post-meeting r2, but I don't have it or a record of what it changed. Did the r1. As instructed, because paper 115 passed, I did not do the edit in 1.1 of this paper. ", and" -> ";" in last sentence of the 253:10-12 edit. [54:38] The inserted material doesn't have anything to do with this section. I guessed that the insertion was intended to be at 53:38, which is at least talking about related things, so that's where I put it. Attempted fixup of the sentence structure of first sentence in the insertion at 346:29-31. Did not italicize "dispatch table" and "slot" in C.10.2. Not sure what was intended here. We've normally used bold for definitions of terms. Or perhaps quotes to indicate a coined usage. I just left them in normal text. paper 01-108r3 with the following changes Also deleted Note 9.55, which referenced the deleted section. paper 01-109r3 with the following changes [193:1],[340:31+] The name of the mode is "delimiter mode", not "character delimiter mode" or "character string delimiter mode". [340:31+] There are other several minor inconsistencies in style in the component descriptions here, and this edit introduces a few others, but they aren't actually wrong and may end up being deleted later, so I'll leave them as is and enter this as is. All the edits on page 193 are superceded by paper 01-171r1, which deleted this area. paper 01-110r2 with the following changes xref changed to 9.8 instead of 9.8.1 (because the r2 found an important relevant statement in 9.8.0). paper 01-111r3 as is paper 01-112 as is paper 01-113r2 as is paper 01-114r2 with the following changes [282:19-27] Better, reduced the indentation so that most of them don't wrap at all. Hmm. I notice that we are inconsistent about whether or not to hyphenate "floating point". I think it should be hyphenated (as this paper does) when used as an adjective (which it almost always is), but I haven't done a global replace to change this. Perhaps I should. For now, left them as is - some one way, some the other. paper 01-115r1 with the following changes It just repeats something mentioned on the floor, and it isn't directly related to the edits, but I'll say it again here anyway... This paper really should have had at least a few words of introduction before jumping into edits. We have had some papers (perhaps some of mine :-)) that belabor the obvious at pointless length, but this is a bit much in the other direction. The casual reader, or even a careful one, might completely miss the pretty important point that this paper is completely removing a feature (select kind) from the language and replacing it with a different feature (generic type-bound procedures). I'm not against doing that, but it would be good if the paper gave us a clue. A year or two from now, if someone scans back to find where and why that replacement was made, they are going to have an awfully hard time figuring out that this was the paper. [41:24-26] "which" -> "that" in the first constraint. (At least I think so. Van usually gets those right, which does at least give me pause). [42:34-35] In the last inserted constraint, moved the "either explicitly or implicitly" phrase right after what it modifies ("specify") instead of after something that it doesn't ("accessibility"). It's also at least slightly confusing what "that has the same " modifies (it's not the "" that it follows), but I left that alone. [47:12+] The second para seems awfully wordy, particularly "the interface of the abstract interface specified by". Besides, I don't think an abstract interface body has an interface - it specifies one. I simplified the cited phrase to "that specified by". Also changed "is the interface" to "is that" earlier in the sentence. [47:40] "referenced by a procedure reference" -> "referenced" (Does the phrase I replaced mean anything? I don't think that a reference references). [47:31-38] This deletion caused unresolved xrefs in 9.5.4.4.3. I just deleted one xref (there is still an xref there to 12.3.2.1, where dtio-generic-spec is defined) and changed another to 4.5.1.5. The edit to <> is on 404:17. paper 01-116r3 with the following changes Replaced all cases of "Programmers can achieve a similar result" with "A similar result can be achieved". Nothing really wrong with the original (except that it should be singular in any case), but the passive wording better matches the style of simillar discussions in B.2. [411:34] Added a comma. [411:39] Deleted the word "valid". It is implicit throughout. Also singularized everything for number agreement (except the "other control constructs" - acknowledging that it might take more than one of them to substitute for a single assigned GOTO). And changed "instead of the assigned FORMAT statement" to "instead of using an assigned integer". There is no such thing as an assigned FORMAT statement (and never has been). [412:3] Singularized. Also removed the "instead of" clause. It is redundant and is inconsistent in style with the other edits. The only one of the other edits that used such phrases was for the ASSIGN stuff, where there were multiple items distinguished by the "instead of". [412:4-5] "." -> ":" [412:6-414:26] "The interested reader is referred to the appropriate locations of" -> "See". This applies equally well to bored reader attempting to use the standard as a cure for insomnia. And it doesn't seem necessary to mention that you will only find information in appropriate sections (just like it didn't seem necessary above to note that the formats used to replace assigned integers had to be valid ones. paper 01-120r2 as is paper 01-122r1 with the following changes There is no "If" on 277:8. I assume the deletion is on lines 7-10 instead of 8-10. paper 01-123r2 with the following changes [151:23,152:20] ", which" instead of "that". The "which" form is the way it was read on the floor. The subsequent clauses don't constitute restrictions on the entity; they describe something that is done with the entity. paper 01-124r1 as is paper 01-125r1 part 4 with the following changes 193:17 It reads strangely to mix requirements on the programmer (allocatables shall be allocated, pointers shall be associated) in with requirements on the processor (editing is performed) in a single serial list. Not wrong - just reads strangely. I separated it into 2 sentences. Then moved the 2nd sentence to be with the newly added para (seems to fit better there - also being a requirement on the programmer). paper 01-126r1 with the following changes Obsolescent font for "is an asterisk (alternate return indicator)". paper 01-127 as is paper 01-130r1 with the following changes delete "section" and "sections" (ISO doesn't use that word). "when" -> "if" paper 01-132r2 with the following changes [12:5-8] Unrelated change while doing this. Reordered so that the most common and important case is first instead of last. [401:15+] The correct reference for component name keyword is 2.5.1. I'm dubious that it's actually worth putting this (and a few others) in the glossary. Outside of it's definition in 2.5.2, I can find the term used exactly one other time in the document (4.5.8), in which context its meaning is clear. I have trouble imagining why anyone would actually ever think to look in the glossary for this (but I put it in as specified anyway, just correcting the section number). [401:31-32] "a" -> "an". [403:12-13] Deleted one comma. (As a rule, don't use a comma in two-item lists joined by "and" or "or". The rule isn't absolute - it can be broken when necessary for clarity. But the exceptions should not be so common as to be the rule. This case doesn't need one.) Added a comma elsewhere. [405:23] Added a comma. [406:16] Used ". It" instead of ", which". The "which" appears to modify "arithmetic". [408:11-13] Reordered to be consistent with the way I reordered the same thing at [12:5-8] [410:4-5] Instead, just deleted the glossary entry for "union", by the same argument as the paper used for "bit field". Grep reveals the word "union" used exactly once in this sense - in the same place and in the same form as the "bit field" usage (i.e. just to say that Fortran can't interoperate with them). paper 01-133 part 1 with the following changes [426:4-6] I think we want "parent component name" instead of just "parent component" in both these cases. [436:7] Also add "by" before "execution" so we can't misread as "preconnection of an open statement". paper 01-139r1 as is Say, weren't we supposed to wait until f95 interps passed before incorporating them into f2k? This paper incorporates interp 24, which is still out for J3 letter ballot (and I see has at least one "no" vote about the wording - though not about the intent) and hasn't even yet gone to WG5. Oh well. Such things are /interp's call. If interp 24 changes, we'll presumably have to track that change here. paper 01-142r1 as is paper 01-143r1 with the following changes pg 170. Did what was meant instead of what was said. (The non-optional keywords are already in order, as there is only one of them). Likewise for pg 175 and 194 On pg 927, all of the keywords are optional, making nonoptional a pretty meaningless criterion (in addition to being inverted in sense). I left UNIT and FILE at the front, as it is required to have on of them (and UNIT can be positional, a criterion mentioned on one of the other edits, even though not one this one). On pg 198, the instructions have been confused enough that I'm left uncertain about the actual intent even in the ones that aren't obviously misstated. I left the sub-clause on FILE first here, corresponding to the bnf. The instructions didn't say to do that, but I don't know whether it was intended or not. paper 01-147r1 with the following changes ", and the" -> ". The" in the edit on pg 83. The original text had this same problem (using a comma between two clauses connected by "and"). The clauses aren't really that closely connected anyway - separate sentences seems better. The edit on pg 131 added text about what to do for nonpointer nonallocatable components that have defined assignments, but neglected to exclude such components from the case covered by the exiting words. Thus they are specified twice (with contradictory directions). I reworded the exiting text to say "for each other nonpointer nonallocatable component of". Also straightened out the pre-existing number confusion in that sentence and the next one by consistently using "each" in each case. Formerly, we started in the singular with "each component", changed to plural with "components", and then went back to singular with "of a type...consistent with the component". It is now all singular. After doing the edits on pg 132, I separated the one resulting unreadable sentence into 3 readable ones. paper 01-150r1 as is paper 01-162r2 with the following changes [96:7+] Deleted spurious comma and slightly reworded to avoid parsing ambiguity. [359:33] add "and" before "has" to fix serial list. [361:24] "those" -> "any" paper 01-163r1 with the following changes [102:34] The two edits on this line don't work together right grammatically (either separately was ok). Used "that" instead of "and" for the [102:34-36] edit. [359:32] Grammatical messup and overlapping edits simillar to those at 102:34. Changed "and" to "that" and deleted a comma. Also substituted "nonpointer nonallocatable" for "that has neither the allocatable nor pointer attribute. We use those terms elsewhere, and it simplifies this sentence noticably. Added "or a subobject thereof" to the edits at 102:38 and 155:16-20. We do need that don't we? (See related unresolved issue 318). Now that it is simplified enough to read, I note that the restriction against COMMON names being the same as constant names sure stands out as unusual (since COMMON names can be the same as variable names). But this is a technical question and is not new. Didn't change it - it just looks odd. I didn't even do a J3 note since this is a feature as old as f77; otherwise I'd have likely done so. In my mind, this is a candidate for a silly restriction in need of dropping. Added an "an" before "intrinsic procedure" to make it clear that this isn't to be read as "constant procedure or intrinsic procedure" (not that "constant procedure" is a term anyway). paper 01-164 with the following changes Changed the new sentence at 118:20-25 to singular (except, of course, for leaving "operands" in the plural). paper 01-167r2 as is paper 01-168r1 with the following changes Add a comma after "C standard" on 394:34 to make the form of reference like that added by this paper at 394:27. paper 01-169r2 with the following changes "which" -> "that" Some other paper also had an insertion at 255:32+. I put this one after the other. paper 01-170r1 as is paper 01-171r1 with the following changes The 6th para of 9.4.5 (new numbering) still is a little inconsistent in talking about values for specifiers vs values for modes, but I left that as is. Extra cases of "rounding" changed to "io rounding" on 167, 174*2, 202*2, 218, 221*3, 222*8 (this isn't all the cases of rounding on 222 - some without "mode" stay as is). "control" -> "mode" twice on 202. 211:12-14 Replace the (incomplete) list of edit descriptors with "the changeable modes (9.4.1)". 218:20 Delete "If" and "is"*2 from table heading, partly to avoid taking two lines after adding Io, and partly because the extra words seemed anomalous anyway. 221:14 "RU, RD, RZ, and RN" -> "UP, DOWN, ZERO, and NEAREST" and add "mode". 222:32-33 ". PROCESSOR_DEPENDENT" -> ", which" partly to help a bad line break, and partly because it reads better anyway. changed all 10.7.5.1 xrefs to 10.7.5. paper 01-173r1 with the following changes In the insertion at 182:20+, deleted redundant xrefs. The xrefs in the first inserted para seem good, but I don't see the point in repeating the same xrefs in the immediately following para, and then repeating one of them yet again in the next para. paper 01-174 with the following changes As discussed on the floor, re-ordered clauses of the first sentence to avoid starting the sentence with lower case. paper 01-175 as is paper 01-176r1 as is paper 01-177r1 with the following changes I don't see where the term "primary argument" used in 13.1 is ever defined. I suppose the intent is clear enough, but the undefined term does slightly bother me. I think it's always the first argument, which is good because I could imagine "primary" getting mistranslated that way. Edits at [277:16], [279:15-18], [280:20-21] mooted by 01-114r2. (Though since both papers end up deleting these sentences, I suppose you could also say that I did both edits). Did not do the edit to move text from [279:33-35] because the section it was being moved to is deleted by 01-114r2. I could have instead first moved the material and then deleted it. Indeed, that might be suggested by a strict literal reading of what passed (since paper 01-114r2 passed after 01-177r1). However, I didn't see that as the likely intent. Still, it's at least a plausible thing to do, because presumably the text in question is redundant (it better be, because it's not specific enough to be the only place this is said.) If we do want to delete this para (the last para in 13.6.1 of the 01-007r1), let me know. [311:14-15] The wording of this edit has the same kind of confusing ambiguity that I had an unresolved issue about somwhere else recently. It reads like it is talking about a type parameter having deferred length. Changed "it shall not have a deferred length type parameter" to "its length type parameter shall not be deferred". paper 01-178r1 with the following changes [64:11+ and 108:7+] Add a "The" to the constraints (to avoid starting sentence with bnf). [108:7+] Put the constraint at [108:8+] (after the whole of R701 instead of in the middle of it). paper 01-181 as is As mentioned on the floor, I remain completely befuddled about what all the words about linking are really saying, but I've entered this exactly as specified, even though I can't follow it. I hope people aren't counting on me to vet this stuff very well - I don't follow it well enough to do so. I think my problems relate to the words used to describe this rather than to the underlying intent. paper 01-182r2 with the following changes Added this sentence to the new para also inserted in the same place by another paper. Added a comma in the C standard ref for consistency of style. paper 01-183r1 with the following changes "an END or RETURN" -> "a RETURN or END" just because that's the way it is done every single other place this phrase is used. Not that it really matters, but my ear noticed the difference from the familliar phrase. Actually, I think it probably to get rid of the reference to specific statement syntax in most of these places and instead use terminology more like that used in one of the other papers this meeting (can't find it right now - I think it was one of Kurt's or Malcolm's) - something about execution of an instance of a procedure terminating, without needing to mention specific syntax. But I haven't done anything about making that improvement. paper 01-185r1 with the following changes Added quotes around the first uses of "name" and "identifier". [235:36] I'm not pleased with how this reads. It sounds awfully redundant to say that "entities..are identified by the...identifiers used to identify them". That's 3 occurances of the word "indentifier" where it seems that one should do. Then the next sentence has 2 more, where again 1 seems enough. I'm also a bit at loss to figure out what the first sentence here is trying to say when it says that an entity is identified by the identifier used to identify it. Is there any actual content to that sentence? I didn't change any of these words - I just don't like them. paper 01-186r1 as is