J3/02-163 Date: 26 Mar 2002 To: J3 From: Richard Maine Subject: Edits incorporated in 02-007R1 This paper describes the changes in J3/02-007R1 relative to the previous f2k draft, J3/02-007. All page/line references are to J3/02-007 unless otherwise noted. This includes edits from papers (all 01-) 104r1, 105, 108r1, 109r2, 110r2, 111r2, 112r2, 113r2, 114r1, 115r2, 116r1, 117r2, 118r2, 119, 120r1, 125, 126r2, 127r2, 128r2, 129r2, 132r1, 135, 136r2, 137r2, 138r2, 141, 142r1, 143, 144, 145, 146r2, 148r1, 149, 150r2, 151r1, 152r1, 153r1, 154r1, 155r1, 156 Typographical stuff not in papers A few Makefile additions and improvements. Look at it and use diff for details if you care. Reorganized subdirs. Changed ui-index template to just use article instead of j3.cls Fixed the font size of four obsolescent examples in C.5.2. (Three were a smaller size than normal, but not the right size for obsolescent; one was just normal size due to an error in conversion from Frame). Removed redundant \tt font specification around verbatims; a bunch in Annex C and a handful elsewhere; should cause no visible change. Changed \_ to _ (conversion error from Frame) at 428:32, 429:2, 430:14,19, and 440:38. Made line numbers a bit larger. Removed some unused and redundant line-number-related stuff in 007.tex, and added a comment about how to turn line numbering off. Fixed indentation in Note 1.2. Added comment in LaTeX source about hack in section title 1.6.3. Ref to Note 12.11 added in first line of Note 12.15 (Error in conversion from Frame). Xrefs to notes now properly say "Note x.xx" instead of just x.xx. (LateX conversion fix). [35:3-10,38:20-21] Fixed font of quotes. Used \cf instead of \texttt in Table 3.1 (same end appearance). [217:25] Fixed the =0, which was a latex conversion error. Hyphenated all 4 occurrences of "machine-representable" (all in 13.7.81) instead of just one of them. [195:22,26] Removed superfluous "(2)" (latex conversion error). Removed extra space in 7.1.3 heading. Fixed bogus index entries (latex conversion error) to the subheadings in the interop inquiry functions (15.2.3). [194:12] Fix font for iomsg. Fixed some other wrong quotes. Newline before R506 on pg 66. [212:16] "beginning" -> "start" (just to shorten an overful line). [225:2-3] "...for the connection" -> "the connection's..." to fix overfull line (can't linebreak in the middle of an xref). Globally lowered indentation of intrinsic argument descriptions from 1.5 to 1.125 inches. They were awfully far indented, making for poor paragraph justification. The 1.125 is still pretty far, but lowering it any more had effects that it would have taken more work to fix acceptably. I put the "(optional)" flag on a separate line in cases where it no longer fit in the shorter spot for the argument name. Fixed xref generation for Table 13.1. (It failed when other changes caused the table to split across pages). In Note 7.34, starting with "then" belongs after the numbered list. [252:14] "binding-name" -> "" (Actually, paper 02-133 did mention this, but I didn't do anything else from that paper. I skimmed it based on the title, but several of the items were taken care of in other papers - possibly inspired by 02-133, and several of the items have substantial technical content - in some cases, content I think is wrong, but in any case, not stuff for me to just do as editor). Did a global search and destroy on all occurances of "%??" in the LaTeX source. These were inserted to mark manual conversion issues. Some are places where there were conversion errors. Many were ok, but would have caused random garbage if the para around them were reformatted. For some, that reformatting already happened (and we had garbage). Some of these have been removed before, but I killed them all this time. Specific cases of garbage were at [80:4] [80:5] [102:20] [103:9] [324:4] Dick noted that C_ASSOC can't be found by acrobat. Looks to me like most underscored can't be found by acrobat; this isn't something I can do much about easily. Majorly redid note environment, resulting in better para spacing and generally improved consistency between material in notes and outside of them. In the process of the above-mentioned note change, since I needed to edit most notes anyway (to change the table rows to paras), also changed most code examples to use the alltt environment (verbatim would also have worked). This makes the code in the LaTeX source more legible by removing most markup from it. Fixed several more missing note xrefs (in Notes 4.25, 5.5, and 7.44). [345:11] remove first comma. ", and" -> ";" Moved a few xrefs in notes out of code comments into leadin text about the code. Putting xrefs in the code comments is possible, but complicates things a lot more than just doing them in the leadin text. paper 02-104r1, with the following notes I'd think it better to follow the lead of 02-136 in having 15.1.0 refer to the Table 15.1 instead of listing all the names. (Might also then refer to the section of module procedures instead of listing those names also.) I didn't do anything about this. Van, no I didn't have to change T: to T15:; j3caption doesn't do that (so far anyway). I blindly changed it at first... and then changed it back when that failed. paper 02-105, with the following changes Left the ones about \kw, \cons, and \jcaption for Van. (No objections - just leaving the calls to him). paper 02-108r1, as is. paper 02-109r2, with the following changes [4:37] Change "the word NOTE" to '"NOTE"' (with quotes), which is the usual typographical convention for referring to a word as a word. [5:2+] I have troble getting LaTeX to parse it at all as an nbdesc (the [] inside of the []-delimited argument appears to cause problems). Gave up after spending not much time at all on it (as I don't see anything wrong with the way it looks now). Feel free to try if you like. I also notice that, although j3.cls defined nbdesc, it is not used once in the document. Defining a new environment for something used only one place, and not even obviously neede there, seems a bit odd to me. paper 02-110r2 (parts 1 and 2 only), with the following changes The r2 missed part of one of the changes agreed on the floor. Namely: the edit for [20:26-27] is mooted by the paper's preceding edit, whoich replaced [20:24-27]. Delete extra "the" at [21"21] paper 02-111r2, with the following changes The r2 fixed only one of the two occurances of "does not appear" mentioned (admitedly briefly) on the floor. I fixed the second one (in the edit for [29:24]) also. [28:22-23] ", and" -> ";". [28:22-23] "that" -> "the next such". (Otherwise we completely dropped that part of the requirement, leaving it unspecified which of the probably many such lines we are talking about; we probably also should have said "at least one" or some such phrase instead of just "a", but I left that alone.) This paper makes some phrasing consistent between the character and non-character cases, but then changes some phrasing that was formerly consistent to now be inconsistent. Specifically, we explicitly state the requirement that there be a subsequent noncomment line for the noncharacter-context case, but we don't say this for the same condition in the character case. If we had taken the part of my suggestion about factoring out all the stuff that applies to both cases (i.e. everything about the noncharacter case), we wouldn't be saying the same thing twice at all. This doesn't merit an unresolved issue; I just thought it odd that we removed one wording inconsistency and added another in the same paper. paper 02-112r2, with the following changes [35:18] "The binary" -> "Binary". I'm not sure what the "the" referred to. (Yes, the old text had similar issues). [35:18-19] -> s. (Is no such bnf term as the plural). [35:20-22] Reinserted "intrinsic" before CMPLX. We are normally careful to specify when we mean intrinsic functions rather than any user-written function of the same name. Looked like the main purpose of this edit was to make the argument association more explicit. I'm guessing that the omission of the "numeric intrinsic" modifier for CMPLX was accidental. It doesn't follow from the application of the same modifier to DBLE, REAL, and INT. Debated whether to also reinsert the "numeric" for consistency, but didn't, as it adds nothing (one might argue for deleting it from the other spot, but I left it alone). [43:18] Could be stated in either singular or plural, but both sides of the "nor" should have the same number. Not "a reference... nor any object designators..". I flipped a figurative coin and used plural (influenced by the fact that C433 a few lines above does so). [51:19+11] Presumed typo. That's Note 4.39. [57:23] Also deleted the "that" before "agrees". [59:12-] I'd have thought the new words a suitable replacement (and improvement over) the existing words, but the instructions said to just prepend the new ones, so I did. paper 02-113r2, with the following changes [68:15] I'd have thought it better to just delete this sentence as something that doesn't belong here and just repeats a few isolated and apparently random things from the place where it does belong. There are lots of other attributes that function results can also have - some of them even as new to Fortran as pointer functins. For example, they can be arrays or be of derived type. But I did the edit as specified. paper 02-114r1, as is. paper 02-115r2, with the following changes [244:25+] Fixed the undefined LaTeX xrefs. (There are no bnf definitions of or ). Also added "then" after the comma. Mostly to improve the line-break. I could argue that the "then" slightly improves readability, but that wasn't the real reason for adding it; I was looking for some way to improve the line break, and I found that. [267:2-3] Moot. Paper 02-136r2 deleted this constraint (and the replacement uses simpler words that don't have this issue). paper 02-116r1, with the following changes [350:29] Also needs "of" -> "for" [315:7-8] Delete the extra "of"s. [361:26] While there also "May" -> "It may" to follow the same form as used elsewhere. 364:21 presumably a typo for 365:21. Other cases on 361:26, 6 places in annex c, 3 in c05 (array-valued, pointer-valued, and character-valued), and 6 in c12 (one being scalar-valued). Left "negative-valued" in c07 alone. paper 02-117r2, as is. paper 02-118r2, as is. paper 02-119, as is. paper 02-120r1 as is paper 02-125, as follows Fixed items 1 and 5-9. Also added 2 close parens while fixing item 9. paper 02-126r2, as is. paper 02-127r2, as is. paper 02-128r2, with the following changes Edit for item 6 overriden by subsequent paper 02-150r2. paper 02-129r2, with the following changes [136:33-34] There is no such bnf term as . I assume you meant . [117:37] Don't add an extra "is" [115:1-3] I believe this to be a technical error, so I didn't do it. I could be wrong, but am throwing it back for reconsideration. My assumption is that things marked as "just editorial" (even when modified by "hopefully") shouldn't raise technical questions at all. I also figured that such marking lowered the odds that anyone else actually reviewed it for technical content. (I know I didn't). The old words said that these were numeric intrinsic operators *ONLY* when used in numeric intrinsic operations. They can also be nonnumeric, nonintrinsic operators. The new words imply that the plus sign in "a"+"b" is a numeric intrinsic operator (assuming the user wrote an overload so that it is anything other than an error). [116:32] Huh? If that's supposed to be a pertinent reference, it is too subtle to be useful in that form. You put it in a context where it is an xref about "function reference", but neither of the terms "function" or "reference" appear in 5.1.1.8, which is about polymorphic entities. I don't think that whatever you are trying to get at here is going to come through to anyone else reading it. Didn't do this. [116:32-33] Presumably this refers to the second occurance of "case" on that line. I also assume that the resulting deletion of the xrefs was intentional, though I'm not sure of that. [117:7] The original words could perhaps use improvement, but I found the suggested replacement word more confusing than the original. The original words are specifically in the context of the preceeding sentence, which is talking about cases where a pointer is dereferenced. (That tie might be made more explicit, I agree). The suggested replacement seems to have lost that connection and talks about "a pointer that is associated" with a target as though there were other possibilities allowed in that context. Besides which, the whole point here is to talk about properties of the primary as a primary - not the properties of the pointer. That distinction is exactly what this subclause is about. We have words elsewhere that say what this suggested replacement says - and elsewhere is where they belong. This actually deleted all mention of the word "primary" from the sentence, making it irrelevant to this subclause. Didn't do this. [117:8] This also appears to be going off and talking about the properties of the pointer instead of the primary. Didn't do this. Perhaps some of this is necessary, but it appears to me that it misses the whole point of the subclause. Since it is labelled as "editorial", I'll assume that it was *NOT* implied to be necessary. [119:20] Agree it needs the "and", but I think it still needs the comma also. Yes, you "normally" omit the comma for 2 things connected by "and" like that, but it's too hard to parse such a long phrase without it. [122:12+] This reads a little strangely to me, but I mostly did it as specified anyway. Except that I did change "whether" to "whether or not". Otherwise it sounds like it is talking about a choice between L(z) vs W(Z), which isn't at all what you meant. [128:17] I don't understand this. Maybe it was supposed to be some other line. There is no "operations" on this line; only "operators". And the xref seems pretty irrelevant. (Plus, putting a xref in a table caption seems odd...and likely to cause problems, though I didn't try to see.) Didn't do this. [129:5-9,19-23] These seem more than editorial. Looks like a couple of dynamic and declared types got switched around for a start. And same type got changed to compatable type. I'll just assume it is all correct. [129:30-31] I disagree with the cited rationale, but the edit seems ok. There is specification of form in 7.1.1, but it is only implication of precedence. But, unlike the rationale, the edit doesn't say that 7.1.1 specifies precedence. No on the "which"->"that". "That" would be wrong here (for either of the two "which"s on this line). The usage here is descriptive, not prescriptive. [130:2] No. I'm not sure how you conclude that most of the subclause has been about "operations". Looks about half-and-half to me, which probably should be made more consistent. (And the subclause title says "operators"). In any case, this one refers to "operators in the same syntactic class". I don't think operations *HAVE* a syntactic class, so this pretty much has to be "operators" unless it is further rephrased. part 4 [132:8-13] The grammatical form of this replacement is confused. It switches from the descriptive form of a definition (saying what an intrinsic assignemnt "is") to the prescriptive form of requirements ("shall"), and then back, in a confusing mixture. Either form will work. You can even mix them. But not in the same sentence. This could be fixed any of several ways. I took the two-sentence route, making the first sentence a definition, and the second sentence requirements. [132:26-27] I assume you just forgot to say to delete this. You incorporated it, almost word for word into the numbered list of requirements at [132:8-13]. I doubt you wanted to repeat it a few paras later. Also fixed a whole bunch of dangling xrefs to the no-longer-existing subclause on intrinsic assiognment conformance. paper 02-132r1, as is. paper 02-135, with the following notes Multipart is ok as is (without hyphenation). It appears that way in the ISO directives. Blanks in Note 7.55 and 8.7. We aren't all that consistent on these, nor do I think we need to be. Examples can illustrate multiple styles (and sometimes do intentionaly). I did do these changes, but I think a global change would be inappropriate. "transferred" is a correct spelling. But I do see one "transfered", which I suspect is what this was referring to. Simillarly "accommodate" is correct, but "accomodate" fixed. "Occurred" is correct, but 4 case of "occured" fixed. The st{dtv-type-spec} in the dt routine interfaces is a latex conversion error; should be dtv-type-spec in italic 225:28 problem appears to be just in the .txt version. Note 11.2. Yes. nonpredictable change? yes. 262:24 Latex conversion error (should be section xrefs) fixed. Note 12.43. quotes fixed. Latex conversion error. Don't know for sure where all the emIn case problems came from (either consistent typo or perhaps a single typo in the conversion program), but I fixed them all. implementors change. yes. nonlabeled do. I think should stay as is. Note we have a bnf term nonlabel-do-stmt. paper 02-136r2, with the following changes Another -> at [270:5]. "[270:7-280:11]" is a typo for "[270:7-271:11]" (This deletes about half a page, not 9.5 pages). [372:23] Delete duplicate "is". [372:24] This deletion overrides an edit on this line from one of the other papers. Note 15.12. Also delete "a" after the 2nd "entity of". After entering the paper's edits for unresolved issue 346, I note that we still follow our own advice in only 3 out of the 12 USEs of ISO_C_BINDING in sample code in the standard. This still doesn't do a lot to convince me that we really believe our own advice, which recommends using ONLY for all USEs of this module. I suppose it beats the former 0 out of 12, but not by much. I am still of the opinion that our failure to follow our own advice is indicative of a problem, but I give up on continuing to point it out. So I just did the edits (including the deletion of the issue) as specified. paper 02-137r2, with the following changes Inserted the new procedure after Note 15.9 instead of before it. (The Note should stay closer to the procedures it is about, particularly if, as is likely, we end up making lower-level subclauses here.) In the last edit, "dummy argument" instead of "dummy parameter". Also make the same fix in preceding para, where this was probably copied from. In the last edit, "and their" -> "; their". paper 02-138r2, with the following changes (12) [347:6] and [348:17] Correctly formed resulting 3-item lists instead of using two "ors". (27) No comma. I also note that the parsing of the sentence is ambiguous, but as either parse results in something that is true and pertinent, I just did it as specified. (It is ambiguous whether it is the IEEE standard in general or the sqrt function in particular that is claimed to have the accuracy requirements.... but either claim would be true). (37) Existing text at [360:9,10] doesn't quite match this, but I did the obvious fixup. Only one case found at [361:12]. I also fixed the other 2 places in C14 where INTENT(IN) was similarly specified - at [354:16,24]. (39) I found the bit about "if a value of FLAG is...." to be confusing, since it is a condition that cannot be false (we explicitly say elsewhere that those are the only possible values for a data entity of that type). But I see that's also what the old words said. I also cannot fathom why the above-cited always-true "if" phrasing is used for IEEE_SET_FLAG, while different, though equally redundant, phrasing is used for IEEE_SET_HALTING_MODE. But "mine is not to question why...". I just did it as specified. (35) For what little it is worth, as the above comment about item 39 reminds me, I agreed with Dick on item 35. I find the repetition confusing in it's implication...though the "It shall be one of..." form isn't nearly confusing as the "if (.true.)" form noted in item 39. I think "if (.true.)" is as poor a style in English as it is in Fortran. This isn't the only case where material that is advertised as helping to clarify things has the opposite effect on me. Those lists of long underscored names also typeset pretty poorly in the narrow indented paragraphs. If you think I'm long-winded and cranky, you should see what LaTeX says about some of these; before I manually hack them to allow hypenation in places that are rejected by normal rules, LaTeX claims they have "badness" of several thousand. (Yes, "badness" is a term it uses for such things.) I didn't do anything on this - just noting. G2 - I griped about this myself in 02-101 (under my comments about paper 01-362r2, [14.8.1-5]. The descriptions here are just ludicrously long. The macro used for this layout doesn't deal with the case where the procedure name and description both take more than one line. It would be a *LOT* easier to shorten all the description names than to try to hack the macro. Besides, they should probably be shortened anyway. Look at the descriptions in 13.5 for examples. I'd rewrite all the "Inquire whether processor supports foo" ones to something like "Is foo supported?". IEEE_REM is particularly bad. We blather on for 4 lines in this short summary, whereas 3 words are apparently adequate later in the full description. G3 - better, just deleted the note. It's two sentences are almost word-for-word repeats of two sentences of normative text in 14.4, except that 14.4 provides context for the "the" here. I'm not sure why it helps to have a note just repeat normative text without change or elaboration. G7 - sorry, but that's English. It is hyphenated when used as an adjective and not when used alone. I count 96 uses with the hyphen and 66 without. Won't guarantee that every one is correct, but the ones in IEEE overflow (14.2) are. paper 02-141, with the following changes Might as well fix them all. Also fixed case on 384:4. And similarly for type-incompatable on [384:1,4], [383:28,37]. paper 02-142r1, with the following changes Delete "section". Don't use that term in referring to the C standard. Preferentially, just omit the term. Where we need to use a term, the correct one is "subclause". paper 02-143, with the following changes [254:9-10] No. This would cause a parsing ambiguity; the existing words were specifically to avoid that ambiguity. paper 02-144, with the following notes 2) "external program units" -> "external subprograms" (There is no such term as external program unit; if there were, it would probably include block data.) paper 02-145, with the following changes Changed xrefs in glossary (associate name, selector), 71:36, and 155:1 to follow the associate-name and selector bnf move. paper 02-146r2 as is paper 02-148r1, with the following changes Ignored the typo in the text to be replaced in item 6. More pertinent, deleted the 5.1.2.12 from [237:4] because the edit makes that xref irrelevant. (That xref is for the protected attribute, which this edit moved to a separate sentence...where that xref reasonably appears). I still think the original words that item 7 is "clarifying" were better than any of the attempts to improve them, but at least lets keep the "improvements" from being technically incorrect. On the floor I pointed out the error in the words proposed by r0 (there is no requirement that the accessibility be given explicitly as those words said), but I missed the error in the r1 words. The "that" in the r1 words makes the "has the PUBLIC attribute" modify "interface", which is wrong; it is supposed to modify procedure. So I used "and the" instead of "that has". This change brings us now almost back to the same words as the original... just substituting "the PUBLIC attribute" in place of "public accessibility", but that's good, I guess, since I thought the original words ok. Hmm. I guess the second case (intrinsic) works ok with either wording, but I kept the two the same. (10) Just a comment. That edit helps. Now I can get almost half way through that sentence before loosing track of what it is about. Formerly, I didn't make it nearly that far. :-( paper 02-149, with the following changes The first edit is to text moved and revised by paper 02-136r2. Integrated these edits by making the following 2 changes to the paras inserted here by 02-136r2. In the first inserted para, delete "and the kind type parameter is positive". In the 2nd, "the kind type parameters in the table"->"these named constants". paper 02-150r2, with the following changes The para in 5.1.1.8 about "type-compatable" sure reads strangely for something that is supposed to be a definition of the term. "Even though..." seems like a really strange way to start a definition. I think the problem is that the paragraph presents things in 100% the wrong order. It starts with the strangest case - one strange enough that it feels it needs to introduce if with "Even though". It ends with the most straightforward case. I'd reverse it. First define type-compatable for non-polymporphic entities; that's the obvious, simple one that serves well to introduce the concept. Then define it for polymorphic types. Finally, mention the special case of unlimitted polymorphic. (The last sentence in the para is about entities instead of types; it could stay last). I didn't do anything about the above. But it's what I'd recommend. paper 02-151r1, with the following changes C505a Added a "The" to avoid beginning a sentence with bnf. Also removed the parens on [49:6]. We don't use parens like that in referring to other intrinsic functions, so now that it is clear that this is such a function reference instead of a special piece of syntax, we shouldn't have them here. (The phrase immediately following explicitly says "with no argument"). Alternatively could have reworded this - I'm suspicious the paper overlooked this occurrence, but it seems acceptable anyway. The edits section had a question, but no actual edit at 3:21+. I did nothing there. (And for whatever it is worth, I think we are compatible with how the internal contradictions in f95 should be interpreted, but that's not my call alone.) In answer to the paper's question about [404:10], I removed the parens there (just like I did at [49:6]). paper 02-152r1, with the following changes The one on pg 28 no longer exists. (Deleted by another paper). Also did one at [6:29] (probably missed because of the capitalization). I think the one at [50:4] (in 4.5.2.3) also means "particular", but this is exactly one of those cases where it is possible to interpret it either way. I could be wrong. Did nothing about this, but someone might want to check. I'd probably not have done the one at [153:37-] (in Note 8.11). I think "most particular" reads a bit strangely, and the "most" does serve to define what meaning of "specific" we intend. (The other meaning doesn't have a comparative form.) But I did it as the paper specified anyway, as it isn't wrong - just a little strange-reading. If you agree with me, might want to change this one back. [342:18] Did both occurances (one capitalized). One case in a new note inserted on the first pg of c14 by one of the other papers. (Referred to "specific features"). paper 02-153r1, with the following changes [106:23] This placement of the insertion doesn't work. We were discussing "An allocatable variable that is not currently allocated". This insertion has a generic statement about all allocatable variables; this leaves subsequent references to "it" without an antecedant. The most plausible antecedant for "it" is then "allocatable variables" (all of them, all the time); I don't think we want to say that deallocating an allocatable variable always causes an error condition, and that the ALLOCATED intrinsic always returns false. I debated moving the inserted sentence to the end of the item, but ended up moving it to a separate para right after these 2 items instead. (It seems to fit with other discussion there). If you want to move it back in, ok, but it needs to either be at the end or some repair of antecedants needs to be done. [108:27,30] I can find references to support that usage of "nor". But changed it anyway to keep Van happy. paper 02-154r1 as is paper 02-155r1 as is paper 02-156, with the following changes Used the symbol infinity. Spelling out "infinity" would also be ok, but we haven't otherwise used the abbreviation INF, so I don't want to. Nothing wrong with the word "magnitude" that I know of. It's a perfectly normal mathematical term - one that we used 23 other times. So used the main suggestion for the first edit, not the alternative.