From maine@altair.dfrc.nasa.gov Thu Nov 30 21:11:57 1995 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 VAA12335 for ; Thu, 30 Nov 1995 21:11:49 +0100 Received: by altair.dfrc.nasa.gov (5.0/SMI-SVR4) id AA02837; Thu, 30 Nov 1995 12:11:50 +0800 Date: Thu, 30 Nov 1995 12:11:50 +0800 Message-Id: <9511302011.AA02837@altair.dfrc.nasa.gov> From: Richard Maine To: sc22wg5@dkuug.dk Subject: Edits incorporated in X3J3/95-007R2 content-length: 19830 (Mallory, please assign this a number and include it in the X3J3 premeeting distribution for mtg 136). ------------------------------------------------------------------- X3J3/95- To: X3J3 and WG5 From: Richard Maine Subject: Edits incorporated in X3J3/95-007R2 GLOBAL CHANGES Changed page headings and title page to paper number X3J3/95-007R2, dated Nov 95. Turned on automatic change bars relative to X3J3/95-007R1 (also known as N1122). Unless there is objection, I'll defer on giving this a WG5 N number for now until the edits have been proofread and accepted. To prepare an Nxxxx version, I'll change the page headings and title page and clear all the change bars. The Frame binaries were converted from Frame4 to Frame5, which is the only version of Frame that I currently have access to. This does not directly result in any obvious changes to the printed document. There are, however, significant differences in the Postscript preamble; the procedure for printing on A4 paper might be different. Globally resized margins to make pages 1/4" narrower so that they will fit on either letter or A4 paper with adequate margins. Split several syntax rules that did not fit within the revised margins. Several notes split over page boundaries, with "(continued)" added to header of second part, to get rid of large gaps. Also edited some of the spacing around notes. Changed note captions to justify left instead of right and make "NOTE" in all caps and bold to distinguish it from normative text. Deleted about 50 cases of excess blanks, where two blanks had been used instead of one, causing anomalous spacing. Some of these were specifically noted in N1153, but there were also several others. These do not seem worth itemizing here. List syntax was very inconsistent and did not follow ISO style. Several people proposed edits that "fix" isolated cases of correct ISO style to make them consistent with incorrect cases. With Walt's help, list syntax was fixed on the following pages. The most common fix was to delete inappropriate colons. Also commas or semicolons as appropriate were added to the end of some list items. Added or deleted words like "the following" as appropriate. Such changes were made on pages 1, 2, 14, 35, 36, 91, 92, 93, 103, 106, 107, 109, 132, 142, 144, 145, 159, 162, 172, 173, 174, 175, 176, 179, 181, 191, 199, 210, 273, 274, 282, 287, 299, 302, and 336. There are probably others that this scan missed, but this should at least move things in the right direction. Changed a few other cases of inconsistent capitalization of multi-word headings; neglected to record the exact places. EDITS FROM N1153 Edits in WG5 document N1153 (reproduced as X3J3/95-278) were incorporated as specified except as mentioned below: xv:30 Used a dash instead of a comma to separate the two phrases. Added a "to" to the second phrase. Also reordered to put the positive part of statement first, giving "Note that this applies only to arrays declared with the ALLOCATABLE attribute - not to pointers." xvi:28 no. The obsolete font convention is not used in the intro. Also, wg5 paper s47 listed "no" for this edit, which corresponds to my recollection of the floor discussion. 1:34 "or" instead of "and". 3:26 moot. Edit at 3:25 deletes this line. 14:16-17 did not capitalize "Type" and "Specification" in the first table note. Such capitalization is for headings only - not in text. I do not understand the instructions saying that the words in the first note should agree with item 14:4-17; I did nothing on them 39:45-47 The insertion is on 39:47 instead of 49:47. 42:3 Retained the word "disassociated". 44:28 Made the rest of the sentence plural to agree with "two types". 51:21 Changed "to invoke" -> "in order to invoke" in the new note in order to make the sentence easier to parse on the first pass. Also "cannot" -> "shall not". 53:5+ Also fixed list syntax of this list by deleting "in the following contexts:" and factoring out the "as". 53:16 The instructions with respect to making [205:14] "read the same" are vague. The original sentence at [205:14] was worded quite differently from that at [53:16]. I had to make several changes in the rest of the sentence to make these words fit at all. 55:6-8 The "but" does not introduce a clear contrast to the preceding clause. After applying this edit, replaced ", but its" -> ". Its". 56:11-17 "ditto" appears to be a reference to the edit 2 lines before instead of the one imediately above. This kind of terminology is very confusing to the editor, who had to spend a lot more time figuring it out than it would have taken to just write out the text of the edit. In fact I first guessed that "ditto" referred to the edit for 56:17 in N1135 and I made the edit based on this guess. Janice subsequently suggested the interpretation above, which I agree looks plausible. 60:26 I used the suggested alternative edit of deleting the sentence. The replacement text needed some work. As mentioned in n1153, the sentence is not necessary, so it seemed easier to just delete it than to spend the time to refine the replacement. 62:8 Left sequences plural because it refers to two of them. 62:17 Deleted spurious "the". 63:26+ Used :: syntax for the integer declarations. 66:32 Used "shall" instead of "must". 73:30+ Used "" in place of "substring-range" and "substring range". 78:4,80:14+,80:15 Used semicolon before "nor". 94:8,94:14(2) Not done. Violates ISO list style. See separate note on list syntax fixes done instead. 94:19-20 Did the edit as specified in N1135. N1153 rejected this on the grounds that it was a circular definition. That objection apparently stems from mis-interpreting the phrase " with limitations that make it suitable...". This phrase constitutes an introductory description that helps the reader understand why specification expressions are being defined. This is not a definition, but more of an abstract of the definition. In particular, the phrase cited above does not and cannot define what the particular limitations are or exactly where specification expressions may be used. That definition follows in the detailed syntax rules. The standard needs more, not fewer, introductory explanations like this. The original text, which N1153 proposes to keep, was nothing but a token acknowledgement of the general principle that sections should start with at least an introductory sentence instead of with bnf. The tokenism is obvious in that the original version of the sentence just translated the bnf rule into a sentence, with no elaboration or rephrasing. This was pointless repetition. It would be better to just delete the sentence and let the section start with the bnf rule (some other sections do). But best is to have a real introductory sentence that actually introduces the material in the section. That is what the edit in N1135 provides. I have therefore done this edit, subject of course, to override by X3J3 or WG5. 94:20+ Edit indicated italics that didn't make sense. I used bold. 95:8-13(which is actually an edit to 116:2+) Used italics for forall-assignment-stmt, pointer-object, and variable. The first 2 are obvious; I presume the third for parallelism. 95:12 Also changed "of an IF statement" to "in an IF statement" 95:37 Edit to add "the" done. Although I agree that the sentence is fine either way, there is almost identical wording in the imediately preceding paragraph. This edit makes the wording exactly identical. 109:25 "occurred" -> "occurs" 114:46-47 Did not do. The original wording exactly parallels the description of DO loops at 126:24-25 in 8.1.4.4.1. We should use the same descriptive model for both cases unless there is a reason for the difference. Either both places or neither should be changed. Also, the proposed edit deletes the specification of the kind, leaving it undefined. 115:30-116:2 The edit instructions are amiguous. I think I figured out what was most likely intended, but it should be checked. 116:11-12 End with colon instead of comma leading into example. 116:18 Made "s" for thr plural of both bnf terms in normal font. 116:19-20 "statement" -> "stmt" in bnf. 118:19 Added a comma for clarity. 129:28-29 Also changed the <= sign to the two characters "<=" because I don't see how to get the single symbol in the obsolete font size in Frame. 143:32+ Omitted comma. Hyphenated list-directed. 146:42-43 Changed ", provided that" -> "if" as the easiest way to fix the line break. 167:3 Made identical change on 166:10 187:19+ Added "they" after "but" in last sentence. 196:20-22 "can" -> "may". "as both" -> "both as". "interface if" -> "interface, provided that the" 200:37-39 "must" -> "shall" 201:37-39 "must" -> "shall" 212:37 Added a comma 213:12 Moved "for intrinsic functions" to end of sentence to simplify sentence structure. 213:11-12, 213:18+ Per X3J3 paper 95-287, did not apply these edits. 213:27 Applied per X3J3 paper 95-287 213:30+ Applied per X3J3 paper 95-287. Substantial rewrite of the note to address the following problems: First sentence was hard to parse. It was also false. The restriction does nothing to allow such things; they would be allowed, and in fact have more flexibility without the restriction. The last sentence correctly states what the restriction is about. Procedure references don't have instances; only subprograms have instances. Wrong use of "must". 215:10+ "were" -> "are" 274:35 Same change made on 274:29. I think the original instructions intended this, but it isn't completely clear. Also "an" -> "a". 285:8 The edits to the edit listed under 285:7 appear to actually apply to the unrelated 285:8 item. Added 2 commas. 295:12 Deleted pure procedure from the glossary instead. The proposed definition is incorrect because it confuses procedures and subprograms. I could change to definition to mimic that given in section 12.6, but that references the term "pure subprogram", which isn't in the glossary. I could add something for "pure subprogram", but I don't really see the benefit of just copying the syntax definitions from section 12.6 to the glossary. I'd think it more useful if the glossary actually explained the term. But given previous controversy in this area, I'm not confident that I would come up with an explanation that would be accepted. Therefore, since neither the definition in N1122 nor the change proposed in N1153 are correct, and since I am not confident of writing one that will be accepted, I've just deleted the definition from the glossary. It seems better to have no entry for it than to have one that is wrong or uninformative. 299:25+ Lower cased "international". 303:9 Replaced "may" -> "can" twice. Ability, not permission, is at issue here. 306:32 Done as specified in N1153, but I do have a comment. I've noted it before, but this citation brings it up again. Section 4.4.1 has nothing to do with pointers; it is about derived types (see the section title). Pointers and derived types are completely orthogonal. The pointer material belongs elsewhere, but it is too late to do such reorganization now. 343:boz constant. Proposed edit deleted the "boz constant" entry, but left 6 other entries that said " boz constant". I changed all the dangling references to " constant, boz", which still exists. 345:common-block-name Also bolded the page number as a defining entry for this and COMMON. I see there are several other index entries that have no bold number and probably should, but I didn't take the time to fix all such cases (except where mentioned by N1153). 346:dummy arguments Not done because I couldn't understand the instructions. There is no entry for "dummy arguments" per se; only for "dummy arguments, restrictions". It is not clear what text on pg 197 is supposed to be relevant to restrictions on dummy arguments. If the intent is to actually add an entry for "dummy arguments", as opposed to adding a page reference to "dummy arguments, restrictions", then there are many possibly relevant things on the page, but it would seem strange to have this be the only page for a "dummy arguments" entry when this clearly is not even the defining instance (which would be in section 12.5). As I couldn't determine what was intended here, I did nothing. 348:intrinsic, function. The particular text tagged for this reference is in section 13.1 and is specifically about intrinsic functions, as opposed to intrinsic procedures in general. It would not make sense to change it. I could have deleted it and substituted a separate reference for "intrinsic, procedure", but I found that the whole area is already referenced as "intrinsic procedure". Perhaps that reference should instead be to "intrinsic, procedure", but that raises a lot of related questions about how many simillar changes in the index should be made. This is a bigger effort than I have time for or than is appropriate for me to do at my own discretion. I added an entry for "intrinsic, subroutine" referencing section 13.10 as the easiest fix to the asymmetry of referencing only the functions. Some of the confusion here is a result of the poor organization of the early part of section 13 in general; the organization is strange enough that it is difficult to meaningfully index. 350:parameter statement. Not deleted. Although I agree that it looks strange and a bit pointless to have entries for both "PARAMETER statement" and right next to each other, why was a corresponding change not made for "OPTIONAL statement"/ and "NULLIFY statement"/, to name two examples that took me about 5 seconds to find? Fixing things like this one line at a time introduces inconsistencies that will later be puzzling. Although it is currently a bit odd to see both entries here, it is at least consistent. While it might be a reasonable edit to delete all of the "* statement" entries in favor of the "<*-stmt>" ones, such edits should be done consistently. I can't see what is special about the parameter statement, except that it might have been one isolated case that someone happened to notice. 350:pointer nullification. Even better, I just deleted the sentence in 4.4.1 that this was referencing (and thus, deleted this entry). The sentence in 4.4.1 that defined pointer nullification had a poorly worded definition that left it unclear whether it was talking about pointer nullification as a general concept or specifically about pointer initialization. This definition was vague enough to be a hindrance rather than a help. Furthermore, a search though the entire document revealed that the word nullification is used in exactly one other place in the entire document (in section 12 talking about restrictions on pointer assignment, allocation, deallocation, or nullification done other than through a dummy argument). The term isn't even used in the section on the nullify statement. The definition certainly doesn't contribute anything to the paragraph that it is in. It seems pointless to define a term that isn't used; particularly pointless when the definition is poorly phrased and in an inappropriate section. 352:statements, forall. Also referenced page 117, which is where the forall statement (as opposed to the forall construct statement) is defined. EDITS FROM WG5 DOCUMENT S21 This document was passed by wg5, but was not incorporated into N1153. Edits from it were incorporated as specified except as mentioned below. 210:39-211:1 "procedure" -> "subroutine" in the new item 2. EDITS FROM WG5 DOCUMENT S40 This document was passed by wg5, but was not incorporated into N1153. Edits from it were incorporated as specified except as mentioned below. 84:11 Also changed "an assumed-size array" -> "a whole assumed-size array" to agree with simillar changes made elsewhere by N1153; this case appears to have been overlooked. EDITS FROM X3J3 MTG 135 Paper 95-282, with the following changes Omitted colon preceding the list in edit 5. Also capitalized the first word in each numbered item. (Yes, this is a strange style, but that's the style currently used in the rest of the document). Reversed items 1 and 3 in the numbered list. Papers 95-287, 95-301R1, and 95-311, with the following changes Note that 95-301R1 and 95-311 rewrite the note added in 95-287. Changed "function" -> "subprogram" in 95-311 and then moved the phrase "in an elemental subprogram" to after "expression". Changed "was primarily added" to "is primarily" in 95-311. Changed "procedure" to "subprogram" in 95-301R1. Used :: in declarations in example. Period at end of sentence in comment in example. Addded underscore in "WORKARRAY" in example. Paper 95-289R2, with the following changes Used arabic instead of roman numerals for both numbered lists; also capitalized the first words of the list items. No colon lead-in to the list in Annex A. Added 2 commas in edit 3 lists of components. Deleted comma before "because" in edit 3. Deleted comma in last sentence of edit 3. "which" -> "that" in last sentence of edit 3. Paper 95-291R1 with no changes. Paper 95-292R1, with the following changes Changed "Rule R918 in section 9.4.2 and the second constraint following R918" to "rule R918 and the second constraint following it in section 9.4.2". Did not italicize brackets in the syntax rule. Space before both commas in the syntax rule. Paper 95-302, with the following changes Added comma in the last edit. OTHER EDITS BY EDITOR 91:21, 92:14, 94:2 "which" -> "that" 94:3 Added "an" before "array" just like in 7.1.6.1. 8.1.4.4.2(1) Replaced second occurance of "the iteration count" by "it" to fix a bad line break with the revised margins. Note 8.14 "will be found" -> "are". Editorial. Slightly changed the layout of Table 7.6 to fit the revised margins. Put the equation in 8.1.4.1.1(3) into an equation box to avoid a line break in the middle of it. Combined notes 4.29-4.30. Note 4.30 was incomprehensible without reference to note 4.29, so combining them made them easier to understand. In several notes in section 4, moved "For example:" to be at the end of the preceding paragraph instead of a separate paragraph by itself. (Among other things, this helped the pagination of the notes). Minor rearrangement of text in note 3.3 to improve subsequent pagination. Deleted "For example" in note 7.38 to improve pagination. In the notes in section 8.1.4.5: Eliminated the example numbers. Used note number instead in the one cross-reference. Moved the code descriptions to the top of the notes instead of the bottom. Improved page break by deleting the lines from note 9.23 that contained nothing but exclamation points. They didn't add anything and were questionable style anyway; the example is noticeably easier to read without them. Also combined the two-line comment into a single line. Moved Table C.1 to after the para that references it instead of before. Tried to get it to split accross the page boundary because of the bad page break, but I gave up on convincing Frame to do this. I don't know why it refuses on this table. -- Richard Maine maine@altair.dfrc.nasa.gov