J3/02-101 Date: 5 Dec 2001 To: J3 From: Richard Maine Subject: Edits incorporated in 02-007 This paper describes the changes in J3/02-007 relative to the previous f2k draft, J3/01-007R4. All page/line references are to J3/01-007R4 unless otherwise noted. This includes edits from papers (all 01-) 350r1, 354, 355r3, 356r2, 359, 361r2, 362r2, 363r2, 364r1, 365r1, 366, 367r1, 369r1, 373r2, 374r1, 376r3, 383, 384r1, 385r1, 387, 388r1, 389r1, 390r1, 391, 394r1, 399, 401 First, note one fix not (yet) done. Paragraph spacing in the notes is globally bad (mostly there is none). This should get fixed, but wasn't going to make it without unacceptable delays in the release of this version. Typography fixes (lines exceeding right margin, blank lines, etc.) at [66:13], [90:6], [93:18], [104:11], [145:12], [154:11], [158:9], [178:16], [199:29], notes 10.11 and 10.12, [265:16] "has a value equal to that of" -> "is equal to" at [284:26] and [285:31]. Done to help line-breaking, but I also think the old version wordier than was needed. Substantial manual hyphenation help, plus turned on \sloppy (so it accepts looser text) in 14. Also hyphenation help in a few paras in 15 (Auto-hyphenation turns off on names with underscores in them so it needs a lot of help with the various long IEEE and C names. Latex conversion errors in failing to use code font fixed in the following places. Found these by searching for code font character tags in the Frame. I didn't try to fix inconsistent use - just to replicate what we had in the Frame. (For example, C.11.2.1 and C.11.3 seem to use a convention that C things are in code font, but Fortran ones aren't. We don't use that convention elsewhere, but I didn't try to fix this). dtv variable in c04 (3 cases), c16, C.12.2. In note 5.19 (3 cases). In notes 7.1-7.7 (multiple cases misconverted as bold instead of code). In note 10.20 and the para before it (several cases). Also fixed the wrong quote translation in the note. In notes 15.14 (2 cases) and 15.16. In C.11.2.1 and C.11.3 (several cases). In 9.4. In 9.5.4.7.2 (a lot of cases throughout this section). other typo/editorial fixes (several from email notes) [2:22] Referenced wrong Annex (because the labels for the Annexes were wrong). [80] 2nd line of Note 5.19. "OROTECTED" -> "PROTECTED" [143:4,19] Reworded section titles of 7.5.4.2.1-2 to avoid bnf in the title. It wasn't typesetting right anyway (due to lack of a suitable bold italic font). The bnf terms are still used in the text of the sections. [183:8,10] Deleted some spurious duplicate words accidentally introduced here during the LaTeX conversion. [186:23] Add blank after "ERR=" [275:18.5] k should be a subscript to f instead of a superscript. [286:2] Insert "then" before "ANY" [286:17] "shall be allowed" -> "shall be allowable" [296:27] "G G" -> "G H" [297:1] "H H" -> "G H" [314:17] Remove superfluous blank before period. [394:4] "" -> "namelist group" There isn't a bnf term. There is a , but we didn't use bnf for iolist here, so I don't see why we'd use it for the namelist group. [402:2] "subroutines" -> "subroutine" [424:1] Fixed xref in c.3.2 section title. Annex E is now a bnf index instead of a copy of Annex D. [498] The numbered list in C536 didn't make it into Annex F. Hacked a fix. Edited each unresolved issue in a way that shouldn't make a visible difference in the 007, but supports a simple way to make a separate meeting paper with an index of them. Added spport for this in the Makefile. Van did several revisions to the j3.cls macro file. See him for details. Minor changes in 007.tex and the Makefile to get "live" pdf links supported by some of the j3.cls changes. (Yes, I know that the table of contents doesn't have live links). paper 01-350r1 as is paper 01-354, with the following changes Both edits already appear to be incorporated in 01-007r4 paper 01-355r3, with the following changes The "array bounds of an assumed-size array" in C548.5 reads awkwardly (you'd expect a scalar to have array bounds?) and is almost self-referential. I added a sentence at the end of the first para of the section to cover this as part of the definition of an assumed size array instead of as part of the constrint. The addition of one word to the the proposed constraint C548.5 would make it also cover C549. I added "data" after "dummy" in C548.5 and omitted C549. Resolved the wording conflict of "in" vs "as" in favor of "as". (The proposed C549 used "in", but C550 used "as" in the same context). The proposed replacement of C550 is worse than the text that it replaces. Apparently the only reason for this replacement is to phrase the constraint in terms of bnf. Although a laudable goal, that is less important than precision. The existing text is, as far as I can see correct. The proposed replacement talks about an assumed-size-spec appearing and the INTENT(OUT) attribute being specified, apparently anywhere. There is no qualification and the citation of R520 doesn't provide sufficient context to constitute one. It then refers to "the dummy argument", which has no referent. I could probably fix this up...but then I could also just leave the original text, which I did for now anyway. 6) You can't just insert a longish phrase with substantial structure between the words "Identifier that" and expect it to still be clear that the "that" still modifies "Identifier" from which it is now far separated. I added some verbiage to fix this. Also, we more commonly say "accessible in" rather than "accesible to", though we seem inconsistent. (The "in" wins by 29-10). 9) As long as we are fixing this anyway, fix it the rest of the way (by using our current syntax to show this dependence instead of writing it out as a sentence). paper 01-356r2 as is paper 01-359 as is paper 01-361r2, parts 1, 2, and 3.4 with the following changes (line numbers for 007r3) [290:32-33] Also "values" -> "value" (which is implied, but not stated by the edits). [294:24-25] and [321:11] I don't know why we feel it necessary to keep repeating this particular fact, but I did it as directed. [314:38-40] Allocatables don't have targets. But this is more complicated than necessary anyway. The definition status of a pointer is the same as that of its target, so just changed "If its association status is associated, the target" to "It". [315:9] The number agreement of the sentence may be questionable, but that doesn't justify making "type parameters" singular. There is no reason why MOLD would be restricted to have only one type parameter. Debated changing "is" to "are" but I'm not sure that's an improvement. I forget the gramatical rule for cases like this. Just left it alone for now. [315:25-26] Whenever we separate examples into separate paras, we also enumerate them with "case(*):", so I did here also. (It does seem a bit strange way to label multiple examples - I wouldn't call them cases, but I'll stick to the way we've been doing it). [331:22+] We defined the term "standard intrinsic module" in 2.5.7 and used it in 13.0. Lets use it here. Changed the section title to "Standard intrinsic modules" (which are the only ones it talks about). Also used the term in the new note and added "intrinsic" in the bodies of the new sections 13.8.1 and 13.8.2. It is awfully hard to figure out what the first sentence of this insertion is trying to say. In particular, it isn't clear that the additional public entities talked about are ones in these intrinsic modules. Plus it reads self-contradictorily (sounds like a module may provide public entities in addition to the ones that it provides the "specified in this standard modifies only modules - not entities). I completely rewrote it. (Using the term "standard intrinsic module" helps). I also added an introductory sentence to 13.8. It jarred to start talking about how a processor could extend the modules before even introducing their existence. Not that my sentence says much, but I think it helps the transition. I greatly abbreviated the title of 13.8.2. It was the longest title in the table of contents - long enough to not fit quite right. We don't really need to include the entire section body in the title (which this comes awfully close to doing). I'm not actually sure why we need section headings at all for the single sentences that constitute 13.8.1 and 13.8.2, but I did them as specified (except for this abbreviation) anyway. [331:24-30] I left the first sentence. Otherwise, there is no general description of the module at all, and this section is completely empty. The material added by the paper did not include anything to replace this first sentence. Second set of edits in part 2. Did the same edit for the SUM intrinsic. I note that the justification proposed for the ICHAR change is contradicted by the result value specifications for both the CHAR and ICHAR intrinsics (they explicitly state some things to be true for "any character capable of representation in the processor"), but I didn't do anything about that. The justification is not part of the passed edits. As the standard reads, it would appear to me that it forbids the situation mentioned in the justification. The edits don't change that. I made edits for ICHAR in 13.5.3 and 13.6. (Seems like we seldom remember to change those sections when changing intrinsics). paper 01-362r2, parts 1, 2, and 3, with the following changes (line numbers for 007r3) [338:7-8] I note that both sections 13.5 and 14.8 lack a proper introduction. The words given don't actually constitute introductions (and besides, relate more to sections 13.7 and 14.9 that the sections they are in). I'd say that the material deleted by this paper was more appropriate as an introduction than the material replacing it. The old material could easily have just removed the usage of the word "section"; and I'd say this new material belongs in 14.9. But I did the edits as instructed. [14.8.1-5] Ok. Done. I think would look a lot better if the descriptions were shortened so that most of them fit on one line, though. These are supposed to be one-line descriptions, not complete specifications. For a particularly egregious example, the IEEE_REM function uses a perfectly fine 4-word description, but then elaborates enough to require 3 lines in this format. The "detailed specification" in 14.9.13 makes do with the 4-word version as a description (properly leaving the elaboration to the result value para), but we apparently feel that this summary table needs to elaborate. IEEE_SUPPORT_ROUNDING has an oddity because the macros don't handle the case where both the procedure heading and its description require continuation lines. I don't see that we can do much about the heading, but we could presumably shorten the description; I'd rather do that than try to figure out how to hack up the macro for this one case. [347:19] I have no clue why we use the phrase "may be scalar or array valued" instead of just "may be a scalar or an array". beats me what "valued" has to do with anything; indeed, we use this phrase in contexts where the entity in question doesn't even have to have a defined value, which makes it really hard to figure out what "array valued" is supposed to mean. But this is far from the only case. Did it as specified...for now. [349:3],[350:15] Also changed "shall include" to "includes". This isn't a requirement; it is an elaboration of what the term "support" in the previous sentence means. We do not require the processor to support this ability (which is what the previous wording implied). We are just saying that if the processor doesn't support the ability, then the previous sentence is interpreted as meaning that the function shall return false. I think that was what the "Here," was trying to get across; it just didn't do it very well. [434:33-34] Fixed the typo ("IS\_LOGB" -> "LOGB"). [346:30-32] The last part of the restriction on IEEE_SET_ROUNDING mode is moot (and thus I think silly). It is not allowed to invoke IEEE_SUPPORT_ROUNDING(ROUND_VALUE,X) if IEEE_SUPPORT_DATATYPE(X) is false; that is explicit and clear (see the edit just a few lines below). Thus the "for some X such that IEEE_SUPPORT_DATATYPE(X) is true" part of this restriction can be replaced by just "for some X". But I've said this before without it getting incorporated, so I'll let it be J3's call. It isn't actually wrong - just unnecessary and possibly confusing. (I find it confusing to have a condition that can't ever be violated; makes me wonder whether I'm missing something.) Notes said to also do part 4 item 2, but that is included in part 1 of this revision. paper 01-363r2, with the following changes I can't find where the alleged ISO dislike is documented, but the edit looks ok, so I just did it. I presume the 2nd copy of directions telling me to change numbers to letters on lines 25 and 27 really means lines 30 and 32. paper 01-364r1, parts 1 and 2 with the following changes (line numbers for 007r3) [365:4-6] I notice that this edit deleted the xref for scoping unit. I'm not sure whether that was intentional or not. I almost did it as is, but ended up adding the xref back in in the obvious place. I was influenced by the fact that one passed paper from the same meeting had a major error from misunderstanding the term, so it does seem worth pointers to. The term is of major importance to this section in particular. [367:25] While doing a global replace to raise the subclause levels as specified, I noticed on this line the only use of the term "subsection" in the document. Changed it to "subclause" top make ISO happy if they ever happen to read to this depth. [366:26] Presume "a..identifier" to be a typo for "a..identifies". [371:19,22,25] Hmm. We seem to hyphenate "derived-type definition" most of the time (21 to 10), including the section title of 4.5.1. ( I might have missed some because of line breaks in the middle of the phrase.) The hyphenation is technically correct - it doesn't mean a type definition that is derived. Hyphenated these 4 cases and the 10 others. [371:26] I grumbled about this before, but it seems to have passed unchanged, so you get it as is. Still sounds to me like it is referring to a single scoping unit (as opposed to all scoping units having access to an object of the type). [372:6,7] I notice that this sentence can't seem to decide whether it is referring to a variable or a name. But that's in the existing words - not new to this edit. [376:5,12] Also twice on [376:10]. I missed those cases in my prior review because my mind (and grep) was narrowly looking for "associated to", whereas these forms are "association is to". [376:25-34] I thought the previous wording of the note better; it talked throughout about pointers. This version talks about pointers, switches to talking about the association status, and then uses "they" in a context that refers back to the pointers. But you've got what was voted in. [377:9] I did this as specified, but I'm not sure whether it is correct. This doesn't say the same thing at all as what it replaces and it doesn't match the way I though things worked. Seems to me that this contradicts 12.4.1.2, which says "If a dummy argument has INTENT(OUT), the corresponding actual argument becomes undefined at the time the association is established." I don't see how an object can become undefined at the same time that one of its pointer components becomes dissassociated. Hmm. but 4.5.10 seems to support this edit. Perhaps I'm just confused. Or maybe the draft is. Or both. [379:29-31] I assume this replaces the whole para (lines 27-31) instead of just 29-31. "Note to J3" following the edit at 379:29-31. I couldn't tell whether this was intended to be added to the draft as a J3 note or was just a note in the meeting paper. I waffled back and forth more than once (indeed more than twice). In the end I did nothing with it, but I'm still not sure whether that was the intent. [380:52] Presumed to be typo for [380:32]. [383:25,26] Why? This just changes 2 words into 8 and complicates the sentence structure with an extra clause. Is there some reason why we need to do this for SAVE, but don't also feel obligated to turn nonpointer into "that does not have the POINTER attribute", and likewise for nonallocatable? Is there some objection to the term "unsaved"? If so, we better fix the other 9 occurances... um...along with the one of "nonsaved" introduced earlier in this paper. Didn't notice that at the time, but I'll change it to "unsaved" for consistency. I'm indifferent as to whether we say unsaved or nonsaved, but we probably should use only one of those (or switch to "damned" as I think has been suggested before :-)). Didn't do this. [384:19] Previously done in response to an email note (see "other typo/editorial fixes" above), but with a slightly different edit (switched to non-bnf). P.S. Run-on sentences are hard to read and its nice that someone on the committee knows how to use semicolons. ;-) paper 01-365r1, with the following changes (line numbers for 007r3) [390:22-23] Unboldened "disassociated" in the copied text. [390:27+] Also added 12.2.1.1 to the ref list. [391:6] Not really related to this paper, but I'll just note that this is another one of the several poor definitions that doesn't actually define anything. It doesn't say a word about what having an explicit interface actually means. Instead, this just lists the conditions under which something has one. The result is going to be just a blank stare from anyone who doesn't already know what this is really about. This paper did improve some simillar non-definitions (like the ones for disassociated and dummy argument). [393:20-21] It seems circular to define a main program in terms of a Fortran main program. And neither this nor the old definition actually say what it means for something to be a main program - just what the syntax of one is. I'd say that a more useful definition would say something relating to the place where execution starts. But I just did what was passed. [396:23] Unboldened "disassociated" in the copied text. paper 01-366 as is paper 01-367r1, with the following changes (line numbers for 007r3) [421:9] Same change on 421:24. [433:24] I noticed about 6 other simillar uses of this phrase in the Annex, but I left them alone, though it would also be fine to fix them if J3 so directs. [433:30-33] I see no contradiction here. I don't even see any point that I'd think subject to question. Nothing in the standard requires interoperability with a f77 processors at all. Nothing in this standard even requires f77 processors to exist (which is a lot like the possibility mentioned here of disallowing any reference to f77 procedures). I think you are misreading something if you see any sign of contradiction here. However, deleting the material is ok. As you say, they don't contribute much. I don't see a pressing need to remind vendors that incompatibility is allowed. So I did the edit as specified. paper 01-369r1, with the following changes The first edit is a line 788 instead of 778. [13:32] LaTeX code shown doesn't actually work (because Table 2.1 doesn't have a label). Added a (shorter) label of T2:Ordering and changed this to refer to that. [53] Same kind of error also on the 2nd line of the note. [100] Also used hard blanks (~) to fix comment alignment in Note 6.8. I bet there are more cases of this problem in the LaTeX conversion. Hmm. Should probably convert these to use a verbatim environment. Van agrees, but says it was tricky to auto-convert from Frame that way. To look into later. [221] Added the newlines as suggested. (Used a parbox.) [256:14+2] I wouldn't have taken any work at all to convince me to just delete this note. It's not as though it says anything. The astute reader who even made it to chapter 12 is likely to be able to guess that material about the intent attribute might be found in the section on...the intent attribute. But I just did what was directed. paper 01-373r2, with the following changes 1) Did not capitalize "section". 5) I'm going to have to "punt" to Van on the paragraph spacing in the notes. It isn't just this one. None of the notes appear to have proper paragraph spacing. Possibly something related to them being implemented as tables. I did try to turn this into 2 paragraphs instead of 2 table rows, but I'm not sure it had any effect. (See above). 11) The premise in the R0 of this paper is incorrect. Derived type definitions do not contain type declaration statements. They may contain component definition statements, which look similar to a small subset of type declaration statements, but are not the same thing. But I agree that the note doesn't add much useful anyway, even if it is correct. So I deleted it as instructed. 14) Paper failed to mention what version of the 007 it was referencing. Excessive additional editor whining about the half hour he wasted because of this deleted. 17) If I didn't have the R0 in front of me for reference, I'd have never guessed that line 1- meant the last line of the section. Please don't use negatives to mean counting back from the end like that. We have often used that notation to indicate an insertion before line 1. Same comment on at least one other paper. 19) The answer to 19 sounds like it is addressing question 20 of the R0 (and giving the opposite answer from the one proffered in the edits for 20). This puzzled me, but there are no edits, so I'm ignoring it. 20) I added "user-defined" before "derived-type input/output". That's what the referenced section is about, and that's what makes sense. I hope you aren't trying to imply that any I/O of a derived type object is a procedure reference. I'm not sure what the "An occurance" means in the edit for item 20. The way it is used sounds like an execution-time concept. An occurance of output or of finalization sounds like something that happens at execution time to me. But all the other forms of procedure reference explicitly refer to source code in a way that has nothing to do with execution. (I.e. the appearance of a name or designator in the code). This doesn't seem to fit well to me. But I entered it as is. paper 01-374r1 as is paper 01-376r3, with the following changes I entered the paper as is, but I'm not very happy with the wording. (Though I must say it is an improvement over the previous wording - I didn't even know what that "independent" bit was supposed to mean). My main objection is in the wording copied from the preceding para (and thus poor there also). The sentence mixes static compile-time concepts with dynamic execution time ones in a confusing way. "Appearing in a DEALLOCATE statement" is a static, compile-time concept. The pointer appears there regardless of whether the statement is ever executed. However, the property of being currently associated is inherently an execution-time thing. As a smaller point, I'd be tempted to add something like "of a POINTER" after the "created by allocation". Yes, we do disallow allocatables in the para above, but I'd think it an improvement in clarity to emphasize the point here. I don't understand what the "or a subobject" is supposed to add here. All it adds for me is confusion. A subobject *IS* an object - always. Saying "the whole of an object that was created by allocation..." says it all. If the "or a subobject" is supposed to clarify something, it achieves the opposite effect for me. But I entered it as is anyway in case this is actually supposed to have some technical meaning that escapes me. paper 01-383, with the following changes 7) You probably meant line 15. Yes, removed the comma there. paper 01-384r1, with the following changes 4) [152:3-4] Added an "a" to the replacement text. [152:5] The r0 said to xref 16.7.5; r1 said 16.7.1.5. I presume the change was intentional and did what the r1 said. (Both sections seemed relevant). 5). Also changed ". This algorithm" -> "; it" instead of starting two consecutive sentences with "This algorithm". 6) I doubt we mean to talk about a reference here. If so, that would make this sentence a tautology. A "reference" is an appearance in a context that requires its value (2.5.5). Appearance in a variable definition context is unlikely to be a reference. I am assuming that the wording of the edit was written with the informal English usage of "reference" in mind; we try to avoid that usage, particular where there is possibility of confusion, which appears to be the case here. The words in the normative text (C809, C815) don't say anything about "reference". I redid the edit to use the wording more like that of the normative text; I did follow the edit's use of "array with" instead of "variable that has", figuring that this might be reasonable as clarification in a note. I used the "vector subscript" of the normative text instead of "vector valued section subscript" of the edit. We just use the term "vector" instead of "vector valued" in this context. I'm not sure what "valued" adds here. Grep doesn't even find the term "vector valued" (with or without a hyphen) in the document. We do have 15 cases of "array-valued" and 25 of "array valued", most of which I think are silly. 7) I don't understand the inconsistent placement of these two copies of the same sentence. The copy for the asociate construct is in the section on execution of the construct, a section in which the term "asociate-name" doesn't even appear. The copy for the select type construct is in the section on form of the construct. The section on execution of the select type had a word-for-word identical copy of the paragraph we edited for associate; if the edit did belong there for associate, why isn't it also there for select type? Also, I note that the proposed copy in the select type section was right after a sentence that elaborates on the distinction between the syntax with and without an . If it hadn't been that much in my face, I'll confess that I also might have failed to notice that the edit refers to the bnf , which might not exist. It should instead refer to the non-bnf "associate name", which always exists. I put the edit one place instead of two inconsistent ones. After debating between sections 8.1.4.0 and 8.1.4.5, I put it in the former. To go along with that, I rephrased 8.1.4.0 to introduce the term "associate name" there and make that the defining instance. That para kept "dancing around" the term without actually using it. It seems a more appropriate place to put the definition than buried at the end of the section on the form of the select type construct (where one might even conclude that it didn't apply to the associate construct. While writing this definition, I noticed that the former last sentence of 8.1.4.0 appeared to apply only to the associate construct because never in that section was it mentioned that a named entity had anything to do with a select type construct. And I also revised the description in 8.1.4.0 so that it didn't imply that and associate construct could have only one associate name. Wow, a bunch of problems in that para, much of it not directly related to this paper. Perhaps I should have done an unresolved issue. (Probably would have if I had done this paper later and felt time pressured). paper 01-385r1, with the following changes 1) "the selector" => , italicize , and "type-guard-statement" . It is possible that we might want to change other cases of "the selector" to , but I'll leave that call to J3 (including the call of changing this one back). I assume I wasn't supposed to do anything about the "If we do this statement." It had no specifics. (And I disagree with it. I think we are already ok here, and I think we already far over-use "if any".) 7) "must" -> "shall" 8) I think this overkill, but I did it as specified. The phrase "same bounds" appears in chapters 4 and 7. I didn't go searching for other comparable phrases among all 78 occurances of "bounds". I'd think it better to just make sure it is well-defined instead of repeating this mouthfull each time. But whatever... By the time you put two sentences between "associating entity" and the "It" of the final sentence, the antecedant is lost. "It" -> "The associating entity". paper 01-387, with the following changes [xii:4] If anyone cares, that same typo is in f95. It's from the fluff that ISO provided (the part that gives credit to all kinds of groups except for the ones doing the work). [23:29] The 0 appears in the LaTeX source, but appears to have been "swallowed" by a bug in Van's "\inp" macro for indented paragraphs. Probably didn't show up more because paras don't often begin with digits (except for code, which tends to be done differently). Same bug in the "\hin" macro. Fixed both of them. paper 01-388r1, with the following changes [229:25+] I'm not sure I like the "allows documentation", as I think documentation is allowed anyway. I've certainly implemented namelist-like syntax or other forms of input documentation in the past. Perhaps "provides" or "facilitates" might be better. But I entered it as is. paper 01-389r1, with the following changes No hyphen in "nonadvancing". Used "has no effect" rather than "is ignored". I don't see any normative text justifying the claim that these specifiers are ignored. I can see that they have no effect. Also, "An" instead of "The". (This isn't a specific EOR= specifier - but any one that meets the stated conditions). Didn't capitalize "read" referred to as an operation. It would be capitalized in reference to a READ statement, but not in reference to a read operation. paper 01-390r1, with the following changes The proposed definitions of dummy and actual arguments appear to be wrong to me, as mentioned in paper 01-382, but I documented that objection prior to this paper passing, so I assume that J3 did this knowingly. From these definitions, it would appear that subroutine, function, and entry names are arguments (both dummy and actual), function result names are dummy arguments, and X is an actual argument in "call sub(x+y)". So be it. Other wording problems also. The following are *NOT* fixed. Apparently argument association causes *ALL* entities in the invoking scope to be accessible in the procedure; we don't restrict this to actual arguments. I suppose the next para is making some attempt to restrict this to actual arguments, but being in a separate paragraph, it isn't clearly tied to the statement about argument association at the beginning of the preceding para. I forsee interp requests. I used to think that dummy arguments had names; I didn't know that they actually were names. Must be one of those branches of philosophy where a name not only identifies an entity, but actually is the entity. [263:12] Capitalized "pointer" before attribute. While on the subject, did the same to the only other case of this I found, and also to the only lower case version of "allocatable attribute". Both were in the numbered list in 16.7.5. paper 01-391, with the following changes 1) I came close to doing this edit and writing up an unresolved issue on it, but decided that would just make more work for all concerned. Instead, I just refrained from doing this at all. You really, really don't want to do this. It would cause major technical problems all over. Yes, things can have scope other than scoping units. Yes, the terminology is confusing. But that's the way it is. Read the first para of chapter 16, where it defines the 4 possible scopes: global, local, construct, and statement. The local ones are the ones that have scope of scoping units. The paper references 16.1.3, but fails to notice that 16.1.3 is not a subsection of 16.1.2, which is where variables local to scoping units are discussed. Note that host association (16.7.1.3) doesn't go into these new "scoping units", so they can't access anything from their host. (And since they don't have any other way of accessing anything outside of themselves, this makes them pretty useless). If we do make host association go into them, then we get a bunch of other "interesting" side effects. You don't want to go there. Being a scoping unit means a lot more than that some name might have this as its scope. If you want me to do this anyway, beat me over the head next meeting. (But its wrong). If you want to improve the terminology so that other people don't make the same mistake (you aren't the first to do so), I could see merit in that. Its a fair bit of work. And I've been told in the past that changes like that don't fly very well because of all the existing textbooks that use the existing terminology. Feel free to try. 5) I didn't do this one either, though it isn't as big a deal. It would just make the examples inadequate and thus confusing. UNIT and KIND are so statement keywords. And without them, this text would fail to give any examples of a whole major class of such. A statement keyword is *NOT* just the first thing in the statement. That's not what this para says and that's not what it means (but that's what all the examples you'd leave would be of - inviting confusion). Again, I have the feeling that this wasn't actually read before it was passed. 8) I don't actually think this edit is correct either, but I did it anyway. It isn't as sure a thing as the ones above. This is a list of places where the component appears individually. There are all kinds of places where a the derived type object can be referenced as a whole, implicitly including the component. Passing as an argument for one. Unformatted I/O for another (this text mentions only formatted, because that's a case where you can see the component as a separate thing. I expect I'm going to be pulling this edit out in the next revision, but I'll let J3 tell me to do so. There might be arguments for rewording the whole sentence, perhaps so that it doesn't claim to be a complete list, instead of just going back to the prior version. paper 01-394r1, with the following changes [35:19+] Since we already had an interp to fix this error in f95 (the very first edit in f95 corrigendim 1), let's not put the same wording error back into f2k. Before "in a DATA statement" inserted "as a that is a" -> "The" because we established enough context for this in the preceeding sentence that we don't need to repeat it. Likewise changed "the constant" -> "it". [305:16+] Used exactly the same phrasing as for the DATA statement, instead of the version here, which was almost the same, with inconsequential differences. (The version for DATA was a tiny bit simpler in structure in one regard). [326:2+] This new case is exactly the same rule as case (i). I was tempted to just add boz to the list of things that case(i) applied to. But I did it as instructed instead. (As is, it does make the 3 cases under characteristics parallel to the 3 under value, which I suppose has merit). [326:2+,7+] Not directly related to this paper, except that it is making two extra copies of an existing awful phrase. Changed all 3 instances of "the processor-dependent kind type parameter for the default real type" to the far simpler "that of default real type". We use the simpler phrasing with the INT intrinsic. And I think I recall one of the other papers from this meeting making the same wording simplification in another case of a phrase very much like this. (Later...actually, it was exactly this case, simplified in paper 01-361r2, so regard this change as integrating the edits of these two papers). paper 01-399, with the following changes 2) Obeyed the description instead of the line numbers. (186:32 was the header of the next section - left that). 3) I found a total of 17. Changed most of them as directed. Just deleted the ones on [187:7] and [187:32] as they otherwise resulted in 2 xrefs to the same section in a single sentence. The one in Note 9.59, and all those at [207:6,18,29] became self-referential (to one level up, but still...), so I deleted them also. (Later...Oh, I see the ones on pg 207 end up getting superseded by rewrites anyway). 7) "IOSTAT specifier" -> "IOSTAT= specifier" for consistency. (Probably was a typo). 8) I really dislike these "if any"s. They disrupt the flow of the sentence and are often superfluous, but I did it as directed anyway. The other changes made the word "also" on [207:10,23,36] clearly inappropriate. The occurances of "also" on [207:12,25] and [208:1] are less clearly wrong, but are confusing; they could be misinterpreted to mean that the IOMSG variable is not defined unless there is an IOSTAT= specifier. (but it wasn't clear, so even if that *WAS* what we meant, work would still have been needed). Deleted all these "also's". 11) Made the obvious list punctuation changes. I'd think this better referring to "input statements" instead of using the specific statement name "READ". But did it as is. (The new text is, after all, consistent with existing text; I just don't think the existing text reflects a very good choice. The distinctions, admitedly are less obvious for input than for output, where one is likely to forget about PRINT). 12) If it is ok to say "If an EOR= specifier appears", then it must also be ok in the same context just a few lines away to say "If an IOSTAT= specifier appears" instead of turning the "appears" into 4 words as in "If the input/output statement contains an IOSTAT= specifier". I changed all cases of the long form to the short form in the itemized lists in all these 3 subsections. (I left the leadins before the lists as is; their context would have also needed an "in which", making the wording improvement arguable). 14) I seriously doubt that you mean what the "Otherwise" in the new text actually says. It refers to the "if" clause in the preceding sentence, not to the "that" clause. Thus, this would imply that the numbered items are done when there is no end-of-file condition, which certainly isn't what you mean. I used instead the same style wording as used for the ERR= specifier. It is a little wordier because it repeats a longish phrase, but it has the compensating advantage of being correct. paper 01-401, with the following changes 10) Uppercase pointer and allocatable used as attributes. 10) This (and the previous wording) defined "ultimate component" as something that a type has rather than something that an object of the type has. Of all the uses of the term, it is clearly applied to objects (as opposed to types) in the 3 cases in c16, 2 in c09, 1 in c06, and one of the two cases in c05. The other case in c05 is naturally talking about objects and uses awkward wording to use "ultimate component" as applying to a type; the wording would be simpler by referring directly to the object. The two uses in c04 (defining numeric and character sequence types) are the only ones where it is used referring to types instead of objects; those uses aren't very hard to fix. I changed the definition and example here and in Annex A to refer to objects, and I fixed the two contrary uses in c04 and the one in c05. Hmm. I wonder whether we are simillarly inconsistent about the term "component". That's a bigger question (far more uses) and would likely be messier to fix if it were inconsistent. Well, if J3 wants to go back to making "ultimate component" inconsistent, my changes on this are easy enough to undo. We don't often (ever?) just start notes with unadorned code. (Besides, the spacing looked bad when I tried to here). I moved the descriptive line of the note to the top instead of the bottom, adding a "defined below".