J3/99-175 Date: 24 June 1999 To: J3 From: Richard Maine Subject: Edits incorporated in 99-007R2 This paper describes the changes in J3/99-007R2 relative to the previous f2k draft, J3/99-007R1. All page/line references are to J3/99-007R1 unless otherwise noted. All of the changes mentioned in this paper have been done in the draft. Although there may be some questions raised below, they do not necessarily require action in my opinion. Those issues which I believe to require action have been put into a separate paper of unresolved issues for addition to the 011 document. This was done to help highlight and track the items requiring action. Ths change bars in 99-007R2 are relative to 99-007R1 Misc editorial/typo fixes not included in passed papers. [21:5] "described via" -> "described by" [43:23] Italicized component-def-stmt. [140:27] Not obviously wrong, but the difference in wording choice for otherwise identical statements bothered me, so I changed the "any.....or" phrasing here to "each....and" just like the corresponding statements for constant and initialization expressions. Moved Table 2.1 to the end of section 2.3.2 instead of before it. Its more appropriate where I moved it to anyway. I think the only reason it was placed before 2.3.2 was for better pagination, but the pagination now works better with it where it belongs anyway. [261:42] "may appear in no" -> "shall not appear in any" paper 99-125r2, iostat_end and iostat_eor, with the following changes In the c9 edit, xrefed the specific sections for the 2 constants, rather than the section 1 level higher. paper 99-131r2, issue 15, as is paper 99-140r2, issue 191, with the following changes Deleted redundant "shall" from item 5. Fixed list syntax. paper 99-143r2, Observations concerning section 12, as is paper 99-146r3, issue 9, as is paper 99-147r2, issue 143, as is paper 99-148r2, issue 16, with the following changes Omitted the word "clause" from the edit at 269:6. We don't define the term and this sentence seemed clear enough just omitting it. Added a comma at the end of the 269:12 edit. paper 99-149r1, issue 35, as is paper 99-150r1, issues 77 and 131-133, as is paper 99-151r1, issue 139, as is paper 99-156r1, misc edits, with the following changes I worked from a copy of r0, with the R1 changes hand-marked; might be worth checking that I got them right. In particular, I'm not entirely sure that I got the R1 changes on page 41 straight. My markup says to just delete the unresolved issue 146 here, but to make no changes in the constraint that it refers to. I recall discussion about this constraint, and I recall that someone found a more general constraint that makes at least most of this one redundant, but I don't recall whether we decided to make any change in this one or not. I'm just deleting the unresolved issue and leaving the constraint as is, according to my markup of what I think was passed. The subsequently-passed 99-168r1 seems to answer the need mentioned in the proposed J3 note about needing the intro updated to reflect f2k. Thus I just omitted that note rather than adding and resolving it in the same batch of edits. Added "(Interoperability with C)" after "Section 16" in the intro, following the style of the other section descriptions. "declared" -> "defined" before "by means other than Fortran". That's the terminology we use elsewhere. Reordered phrases in the sentence at 291:13 to avoid the awkward comma use. In the edit at 292:19, "defined by" -> "described by". We don't really consider a prototype to define a function, do we? paper 99-157r2, select type, with the following changes Added a "The" to the 2nd edit to avoid beginning sentence with bnf. paper 99-158r1, IEEE, with the following changes Note that the edit at 385:37 is superseded by paper 99-167r1. Used lower case for "public" in item 4. One could probably justify either usage, but we seem to (mostly) use it in lower case in contexts like this. paper 99-159r1, recursive I/O, as is paper 99-160r1, fixups to 16.2.6, with the following changes Ignored the typos on the first page of the paper and worked only from the edits on the second page. In the new note, "VALUE" -> "The VALUE attribute". Also "cannot" -> "may not" insomuch as it certainly is *possible* to do so; we just disallow it. Just use the section number without the word "section" in xrefs. "as" -> "because". I assume that is the sense meant. The sense "like" would also have been plausible but would mean something entirely different (and wrong insomuch as Fortran allows copy in/out for arrays). "in C arrays" -> "arrays in C". I'm dubious of the choice of tense in the note. "would have been" and "to have permitted"? Present tense would seem more consistent to me. But I entered it as specified. And my misgivings weren't serious enough to justify a J3 note. paper 99-162, issue 76, as is paper 99-163r1, issue 130, with the following changes Spelled "nonexecutable" the same way both times (without a hyphen). paper 99-164r1, issue 44, as is paper 99-165r1, IEEE cont., with the following changes "An" -> "A" in edit 15. Also don't italicize the second usage of "intrinsic" in the entry - just the first. (twice). I think the statement that was added as the 2nd para of 11.3 might be better put as a 3rd para of 13.0. But I left it as specified. I don't feel strongly enough about it to make a J3 note. Still, if others agree, I'd suggest moving it. While making the specified index changes, I also singularized the plural entry. Singular is usually preferred. I see that the index does have several apparently random and inconsistent uses of plural, but I didn't try to change them all - just the one I was editing anyway. My notes about the R1 changes were unclear about which of 2 versions we ended up passing for the words of note 15.1. I used the version that seemed best to me, though either version seems acceptable as a note. paper 99-166, issue 10, as is paper 99-167r2, more IEEE, with the following changes Used "colonial" spelling of "inquiring". "the" -> "that" in 2nd mention of IEEE standard, since other IEEE standards exist and the intro can't depend on section 1.8, where we state our use of the term "the IEEE standard". The R1 seems to have accidentally lost the instructions on what to do with the item labeled (5a). I found those instructions in the R0 and added this item at [143:23+]. "the reals are supported with IEEE arithmetic" -> "the processor supports IEEE arithmetic for default real" Because thats the form of wording used in IEEE_SUPPORT_DATATYPE. Also because I'm not sure what "the reals" means; I know that "default real" means the right thing. "other values" -> "values that are not in one of these exceptional classes" to avoid possible confusion in interpreting "other". I did the deletion specified by edit 25. I don't know how to do it "subject the approval of WG5" unless perhaps that meant to wait until WG5 approved before doing it. (The whole document is, after all, subject to the approval of WG5). Presumably if WG5 disapproves of this edit, the sentence in question can be added back in (which is easy enough to do). Did the overflow change only on the last of the 3 occurances on [402:15]. Also did simillar overflow/underflow changes on 388:22, 392:8, 392:11. paper 99-168r1, foreward, with the following changes This paper seems to have been reformatted with different line breaks than the text from 99-007r1, so it is more trouble than it is worth to use a tool like diff to find where the actual changes are. I did only the parts where I noticed that there were changes. No promise that I got them all. In fact, my second pass through found several that I missed the first time. I didn't do a third pass. In the 5th para of the forward, "third" -> "fourth", "second" -> "third", and "1991" -> "1997". One of the other papers added foreword material on IEEE, presumably answering the request for that, so I did not insert that J3 note. paper 99-169r1, section 1, with the following changes Omitted "or an interface body" from the last sentence of 1.5.1. It doesn't fit sensibly and looks like a typo in the R1. According to my notes, the "part 3" edits (on f90 and f77 compatability) were not approved, largely because the exact edits reflecting the straw vote were not available to vote on. However, it does look like the R1 incorporates the results of the straw vote about the general direction preferred for this material. Therefore, I've gone ahead and put these edits in on the theory that they will be closer than what we had before. Omitted "the Fortran International Standard," before the references to F90 and F77. Without any qualifiers, I read this phrasing implied that F90 was the current standard. (The simillar phrases in the F95 intro had the words "previous" and "earlier", which made them read entirely differently). Used lower case for "standard". I've never really figured out why this sometimes seems to be capitalized - it doesn't look like a proper noun to me. Consistently used "this standard" instead of "the Fortran 2000 standard". Omitted "note however that", changed the semicolon to a sentence end, and moved the para break by one sentence - i.e. used the same wording as in 1.5.1. Omitted the "as recommended in the Fortran 90 standard with regard to nonintrinsic procedures." I'm not sure why we'd use those words here, but not in the otherwise identical phrase in 1.5.1. Likewise, omitted simillar words in 1.5.3(4). paper 99-170, editor's edits, with the following changes "a" included in the text to replace at [202:35] paper 99-161r1, index entries, with the following changes Added modifiers to lots of the entries. For example, "BINDNAME= specifier" instead of just "BINDNAME=". Similarly used "function", "attribute", and perhaps some other modifiers - too much trouble to list them all. Used the specified page numbers as a rough guide, in conjunction with Frame's search. I made an entry for "C address", but without the quotes. C-type isn't strictly a bnf term. At a little loss what to do instead, I considered indexing C_*, but decided that notation would need definition, perhaps just C_. Ended up using C_(C type), as we do use parens elsewhere in the index for elaboration. Simillar conundrum for IEEE, where I settled on just IEEE_. "child data transfer input/output statement" seems like a pretty big mouthful for an index entry; it won't even fit on one line of the index. True, that's what is bold faced, but should it be? We freely refer to data transfer statements all over, without feeling the need to qualify them further as data transfer input/output statements; there is even a section title of just "Data transfer statements". Although we define the long-winded term "child data transfer input/output statement", I see that the usage switches randomly between that full form, "child data transfer statement", and "child input/output statement". Simillarly with "parent", where we also use the term "parent input/output procedure". Note that we never have child/parent i/o statements other than data transfer ones. I changed all of these various forms to use "child(or parent) data transfer statement". I then used that form in the index. "currently allocated" doesn't seem like something people would likely look for. (Perhaps under "allocated", but I wouldn't imagine people looking under "currently"). And the cited place in the allocated intrinsic isn't a definition. That would probably be someplace in section 6, I suspect (but didn't look). Omitted this one. I'm not sure that I follow the rationale for indexing 3 intrinsic functions in c13 (extends_type_of, same_type_as, and get_environment_variable), while not indexing the other 100+ ones. So I didn't. Once a reader knows the name of an intrinsic, its about as easy to find in the alphabetical listing as in the index. I could see some index entries by concept as possibly being more helpful than just all the intrinsic names (maybe that's just an excuse for me being to lazy to enter all 100+ of them). I omitted the entry for "flexible array member". The only thing we ever say about them is that Fortran does *NOT* interoperate with them (or with bit fields or unions, neither of which we index). I agree that ISO10646 *OUGHT* to have a defining entry in c4, but it doesn't (yet). The only reference to it in c4 now is in a J3 note saying that it needs to be mentioned. I don't think there is much point in indexing things in J3 notes. I did add an index entry for ISO 10464 (and for ASCII) pointing to the selected_char_kind intrinsic in c13. I figured it wasn't necessary to separately index two different forms of the same root word. Indexed both "interoperate" and "interoperation" under "interoperate". I indexed "linkage" rather than "object linkage". (Of course, since we use the same term for 2 completely unrelated things, the terminology may well change anyway).