J3/99-139 Date: 29 Apr 1999 To: J3 From: Richard Maine Subject: Edits incorporated in 99-007R1 This paper describes the changes in J3/99-007R1 relative to the previous f2k draft, J3/99-007. All page/line references are to J3/99-007 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-007R1 are relative to 99-007 This includes edits from papers 99-104r2, 99-105r2, 99-106r2, 99-108r1, 99-110r1, 99-112, 99-113r2, 99-114, 99-115r1, 99-116r1, 99-117r2, 99-118r1, 99-119, 99-120, 99-121, and misc edits not from papers. misc edits Ok. Having papers that try to spell "nonallocatable" both with and without the hyphen forces me to figure out what to do about hyphens after "non", something I didn't really know well without checking. Strunk and White don't mention it. My Chicago Manual of style is at home. But the first dictionary I checked says "a hypen may be used after and is generally used when the base word begins with a capital letter. A grep in the document for non without a hyphen reveals a bit over 300 cases, whereas it is used with a hyphen in 42 cases. Many of the words showing up in the list of 42 are also used elsewhere without the hyphen. Most of the words are too specialized to be in a dictionary, but I did find 4 of the words we hyphenated explicitly listed without a hyphen in the dictionary. Therefore... I eliminated all the hyphens after "non" with the folllowing exceptions. Left "non-Fortran" and "non-IEEE" following the suggested rule about capitals. (Neither of these appear anywhere without the hyphen). Changed one case of non-SEQUENCE to nonsequence, which is used several other places. Fixed the 2nd R501 be R502 (triggering automatic incrementation of all the other R5xx). 100:67 "strcuture" -> "structure" 301:4 Deleted 2 commas. 382:7 "dimenion" -> "dimension" In reply to questions raised in 99-107, deemed by the editor to be editorial in nature, and not covered elsewhere (though some of these later found to be duplicated in papers I hadn't yet processed). 39:46 "CONTAINS" -> "a " 40:25-26 fixed typesetting of R429 42:35-37 Moved note 4.19 to 41:16+ 48:44 "inany" -> "in any" 58:31 "724" -> "7.5.1.5" 78:27 "when" -> "if" 78:31 Add "procedure pointer" to index. 121:18 "character lengths (R510)" -> "nonkind type parameters (R502)" (thats the new R502, the second of the old R501s). 157:8 "the the" -> "the" 225:10 Added "value separator" to index. 225:17 "r" -> "r*" 341:21 "as" -> "is" 371:3 "IEE" -> "IEEE" 378:4 "COMPLES" -> "COMPLEX" 379:5 "compatable" -> "compatible with" 383:14 "fortran" -> "Fortran" paper 99-104r2, status error messages, with the following changes 1.6.3 defines a scalar- prefix; let's use it. Change all definitions of to use instead of just . Then delete all constraints except for the one on alloc-opts; the term now says it all. Delete most "the" before "" or "" unless they are at the beginning of a sentence or otherwise needed. Added the following 2 edits. Former versions had edits around these places. Parts of the former edits are no longer needed (the parts about bounds or allocation status), but it looks to me like the following cases are not otherwise covered. 106:18 Add ", " after "" 109:19 Add "or " after "" Changed "a message explaining the condition..." to "an explanatory message..." (twice) in order to avoid misreading the original as saying that the processor was explaining something to errmsg-variable. Changed "If no error condition occurrs during execution of an ALLOCATE or DEALLOCATE statement" to just "If no such condition occurs", relating to the longer phrase in the immediately preceding sentence instead of repeating it. Made this sentence a second sentence in the preceding para in order to make the referent tighter. Simillar change in 9.9.2. 182:17+, 182:28+, 182:39+ Changes in end punctuation to fit into the list style used there. 187:37+ Delete an "or"; added a "then". Likewise deleted "or" from 187:34, where the new para obviously copied it from. Also deleted an unneeded and inconsistent "specifier" at 187:36, plus several "an"s in 187:33-37. These changes not really related to the new material - just that it drew my attention to them. Several changes to make the last two paras of 9.5.3 consistent (and, by the way, correct). The two paras cover what should be related conditions, but each para got some aspects wrong. The old para at 187:33-37 failed to cover end-of-file and end-of-record conditions in wait operations. I almost did a partial fix for this by adding mention of WAIT statements before I considered that wait operations can occur during other i/o statements. Thus, for example, we can get an end-of-file condition during some apparently unrelated i/o statement such as a REWIND. Thus, end-of-file and end-of-record conditions should be considered for i/o statements in general rather than just for READ (or READ and WAIT) statements. The new para at 187:37+ failed to cover the effect of IOSTAT= on end-of-file and end-of record conditions. I fixed them so that both paras now cover all these cases. 195:25 The conditions here should relate to the value *RETURNED* in the err argument (like at 195:26) instead of values *ASSIGNED* to it. The procedure is free to assign values to err during its execution; all that matters is the returned value. This is not just a theoretical concern. Real codes often do things like setting an error flag to true initially and then resetting it to false if the code completes without error (or conversely). We don't want to imply that there is any restriction relating to such interim values. Yes, this error was in the original and is not new to paper 99-104r2; but I'll fix it now anyway. Simillar fix in the existing para at 195:21-24 Another side-edit not directly related. Interchanged FALSE and TRUE at 195:21-22. This does not change the meaning, but it seems more idiomatic to say "true or false" instead of "false or true". The change also makes it parallel the "whether or not" later in the sentence; otherwise I suppose a sufficiently perverse reader might infer that the value "false" corresponded to the "whether" and that "true" corresponded to "not". (The words don't quite explicitly say what the correspondence is, though the implication is pretty clear). 207:17+ Singularize the whole sentence. Also, as with the above comments about 9.5.3, generalized to recognize that eof and eor can occur in i/o statements other than READ and WAIT (because wait operations can be done by other statements). And added IOSTAT= to the specifiers for end-of-record; I assume this was an accidental omission. Some edits moved by a few lines, mostly to keep from breaking apart material related to STAT=. Added several commas. Deleted others. While moving subsections of c9 around as specified, I also did one unrelated subsection move. Moved the contents of old section 9.9 (restrictions on function references and list items) to the end of old section 9.10 (restrictions on input/output statements). Neither the subject matter nor the length of old section 9.9 justified a separate section at that level; its one sentence is, indeed a restriction on input/output statements, as it explicitly says. paper 99-105r2, standard unit numbers, with the following changes 171:29 Delete comma before "or". (I'm beginning to see a pattern in this one. Authors should note that commas aren't normally used with an "or" separating just two items even if the items are long. Exceptions can be justified when it really helps clarity, but such exceptions should be pretty rare - not as common as I'm seeing. If you are regularly finding that sentences are unclear without such questionable commas, then this usually means that the sentence should be rewritten rather than trying to rescue it with a comma; all too often, such spurious commas don't really clarify anyway.) A few other changes in the sentence to clarify what the "or" does apply to (the "the same" bit is meant to apply to both "or'ed" things). On the other hand, we do put commas before the "or" in a list of three, four, or more items. Did so. Reordered things in 172:3-6 to say the more important things (that this is for error reporting) first and the details (like that it is preconnected for sequential formatted output) later. Also, used a simpler phrase for "standard output". Just called it "the output unit identified by an asterisk." The longer phrase was hard to read because modifiers were too far from what they modified. In 172:3-6, instead of talking about how a processor might not support separate error reporting, just say that "the processor may define this to be the same as the output unit identified by an asterisk." That is the concrete point to be made instead of the vague phrase "support separate error reporting". Elaborated on "these units". Otherwise its not completely clear which ones are meant. Found it easiest to do this by saying it separately for the * units and for standard error. 194:38 Omitted redundant "unit" (the sentence says "unit" earlier). 194:40 Used bnf for io-control-spec list (thus avoiding the question of exactly what other terminology is best used for it - looks like there is some inconsistency in that). And omitted the xref to 13.16 since we have one in the imediately preceding sentence. 194:40 We don't use a lot of parenthetical expressions in the standard (quite the opposite of my personal style when writing less formally, as illustrated here), and I don't think this is a very good candidate for one. Removed the parens and added a "must" (Yes, this is a case where the ISO usage of "must" instead of "shall" fits) and a "in which case". 273:3+ A system parameter isn't a class of module. Changed to "system environment module". Simillarly for the other two classes named. A module may be used to support something, but "support" is not a module. And lets just call these "sets" of modules instead of "classes". I wouldn't consider this a classification parallel to the classes of intrinsic procedures. (Not that the current classification of intrinsic procedures is very useful, but that's a different matter). And mention exceptions in addition to IEEE arithmetic. 334:24+ Changed the section title. I don't think the proposed title was very descriptive of the module. It happens to have nothing but constants now, but I don't see why that is particularly important; things other than constants might be added. After briefly floundering for a title, I just used the module name itself instead of descriptive words. This is like what we do will all the intrinsic subroutines and with the ISO_C_TYPES module. (The IEEE modules don't have a separate section for each one). 334:24+ "more...than" -> "other...in addition to". The "more than" makes me think that the number of entities means something. In the new note, added "name" before "conflicts". And ONLY in caps instead of quotes. And "the" -> "any" before "USE statement". (There might be more or less than one). Its normally questionable practice to have only one heading at a given level (specifically a 13.16.1 when there is no 13.16.2), but I'll let it pass here because it is quite plausible to imagine that we might later end up with a 13.16.2, so its convenient to have the structure in place. In 13.16.1.[12] I added words about "the same unit as". Otherwise I found it confusing to have "identified by" twice in a single sentence. Added "This unit may be the same as OUTPUT_UNIT." to 13.16.1.3. It's said elsewhere, but I thought it fit well to repeat it here in these terms. paper 99-106r2, allocatable fixes Note to the author: You probably mentioned it to me at one time, but I forgot between then and entering the paper....I found the annotation "J3 note (not an edit)" to be confusing because J3 note is exactly the term used for the unresolved issues. I thought at first that you meant them to be J3 notes and said "not an edit" to distinguish them from the notes that are intended to stay in the standard. Later concluded that you really meant the "not an edit" part (partly because instructions like "remove unresolved issue 78" didn't make sense to me as a J3 note). Try not to use the term "J3 note" unless you mean one of the "J3 notes" in the document... anyway if you want to avoid confusing me. Or if I misread it the other way...don't say "not an edit" if you expect me to actually do something with it; the J3 note terminology is enough to tell me to make it one of that kind of notes instead of the ones meant to stay. Another note to the author: I also found myself confused by the marginal annotations that appear to refer to unresolved issue numbers. Nothing really said what these meant. I deduced from context that they probably were unresolved issue numbers, but it wasn't clear to me whether this was supposed to be directions to me or just commentary. My best guess was commentary. If so, I must say that I spent more time deducing how to interpret them than they probably added. (And if not, then my resulting interpretation was wrong). Since this paper has the first reference to the term "Fortran 2000", which isn't otherwise defined, I added a ", informally known as Fortran 2000" to the first sentence on the intro. The intro will need a lot more work later, but I'll get this one in now (particularly since the corresponding statement for f95 was "lost" by ISO). [xvi:21+] I rather doubt that we have addded "the ability to declare that structure components and objects that are not arrays have the ALLOCATABLE attribute". (For those who don't notice the problem - this sounds like a global option to declare that *ALL* scalars are allocatable, not an option to declare particular things that are allocatable). Rewrote as "the ability to declare the ALLOCATABLE attribute for a scalar structure component or object". [31:1-8] I was slightly confused about the instruction about moving a sentence to 100:13+, because I later found an edit to add a very simillar, but not identical, sentence there. I assumed that the actual intent was to add the new version rather than move this old one. (The new version parses ambiguously, but see J3 note 140 on that). [53:23-26] Spelled out antecedants instead of using "it", which could have been read as (nonsensically) referring to the asterisk or colon. [55:26] (Not directly related to this paper). "with" -> "and has". "allocated with bounds and values" is not an allocation status. [63:1-33] Done. (The paper had an "if I agree". I agree). [63:43] In order to make the constraint actually have an effect, I changed "array" to "entity" instead of "variable". Since a parameter is never a variable, it would be moot to constrain it against being an allocatable one; this would still have allowed allocatable parameters. (Of course, I'm of the opinion that we should allow them - thats issues 9&10 - but this would be a rather subtle way to do so; I'd propose we be more upfront). [68:4+] "type-value" -> "type-param-value" (presumably a typo). And inserted it at [67:43+] instead of after all the obsolete stuff. [79:2+] Added at [79:7+] so as to not put it before the J3 note 15 that talks about "the above constraint". [79:33+] Deleted "simply". Just state it; don't categorize it as "simple". [104:33-34] Instructions said "Delete - covered by 104:28-29". I didn't do so because I see little connection between these 2 constraints. The one proposed for deletion says that you must have an alloc-shape-spec-list in some cases, whereas the one referenced says that it must have the appropriate rank. The constraint about rank is implicitly moot if the list isn't there; and it doesn't even mention deferred shape, which is the whole point of the other constraint. If there is duplication here, then I'm blind to it. Perhaps one of these two constraints could be written to cover both points, but neither does so as written (and I'm not doing the rewriting). ..later. Ok. I half see. The constraint reads a bit funny because we no longer have non-deferred shape allocatable and pointer arrays. It is still needed because 104:28-29 only applies if the list appears. But lets rephrase it to talk about arrayness instead of deferredness. This does mean it might be more reasonable to combine these two constraints into one, but I found it easier to do as 2. If someone comes up with words for a combined one that actually do cover everything that's fine by me. [104:34+] I reordered the constraints to group together the ones about type-specs vs the ones about shape-specs. Although it was correct as is, I changed "If an allocate-object has..." to "If any allocate-object in the statement has..." because I thought it made the point more clearly. (That there is only one type-spec for possibly multiple allocate-objects in the statement). "The type-param-value" -> "A type-param-value in the type-spec". I'm not aware that there can be one and only one type-param-value. Also, the clarification of it being in the type-spec seems helpful in this constraint just as in the one before. Unrelated edit at 104:29. Changed the "pointer or allocatable variable" bit to "". There seems no point to spuriously repeating the details about what kinds of things might be allowed as allocate-objects. Indeed, saying here is more precise. (The errmsg-variable, for example, could legally be a pointer; but even if so, it isn't the pointer this constraint means). [105:1-10] I don't understand the statement that "lines 6-10 are updated and moved downward". But I agree the issue is resolved, so I removed it as suggested. [105:17-40] Used active voice in the 2nd clause of the first sentence; and eliminated the 2nd reference to the ALLOCATE statement in the same sentence. (Its already established what type-spec we are talking about - even more clearly in the active voice form). The type-spec applies to every allocate-object in the statement rather than just one; therefore "the object's declaration" is confusing. Indeed, you need to turn this whole sentence around in order to make sense, because the type-spec doesn't have deferred type parameters. It is the object declarations that might have deferred type parameters, possibly a different set for each object. So you need to attach the nondeferred qualifier to the declarations of the allocate-objects instead of to the type-spec. [107:1-7] Looks like this section (6.4.1.1) got passed over. (I noticed when seeing that the simillar 6.4.3.1 got a title change, but this one didn't). Also looks like changing "array" to "variable" is probably right for all the cases in this section. Did so. I didn't actually scan the entire document to see what might have been missed - just happened to trip over this case, which just looks like having lost one's place on the page instead of having forgotten to look in the area. [107:11] So this is "entity", but every other reference in the section is to "variable"? Hmm... Subtle...and I think you are right, but it took me a while. I'll take it as evidence that this really was thought through. [110:15-17] Gee. You could actually read that sentence? Congratulations. But the problem is not new... Its too abysmal for me to have the heart to rewrite it (and keep it correct). I guess if everyone else is happy, I'll ignore it. [140:19+] Delete "the" twice. Change comma to "then" for easier parsing. [140:24-26] Indeed, I agree that's covered. Wonder whether I just missed that when writing the issue or whether the fix got added later without updating the issue? Oh well. Doesn't really matter. [141:11-19] Added two "the". "can" -> "may". Instructions to remember something seem a little casual, even for a note; deleted "Remember that". [254:29-31] The first sentence is awfully complicated and in a backwards order from what seems best to me. We have a basically simple concept (the type parameters must agree) with some exceptions. In cases like that, it is clearer to have the basic rule first, followed by the exceptions, much like the original first sentence here. The proposed first sentence starts out by listing the most esoteric exception, which you have to wade quite a ways through before finding out what simple idea this is an exception to. I went back to the original order. The only thing really being added here was an exception for assumed and deferred type parameters in the dummy. I also simplified the wording of that. The proposed words ended up repeating the longish phrase "the corresponding type parameters of the associated dummy argument" twice in close succession. I don't think we really need those words at all. We have already established that we are talking about an actual argument and its corresponding dummy argument. I think we can also assume the bit about corresponding type parameters; if we can't then we'd need to say something about it in the basic rule in addition to just the exception (i.e. that it is the corresponding type parameters of the actual and dummy args that have to agree). So I simplified this sentence a lot (and even the complicated version was shorter than this explanation). The character len case is so quirky that I think it important to have the para elaborating on it right after the sentence that mentions it, rather than leaving the reader to wonder for several paras what happens in the complicated case just mentioned. So I kept the material about deferred type params after the para on the character case rather than before it. I'm not sure that I really buy the argument for why we should not allow deferred actual parameters to correspond to non-deferred dummy ones, but guess I'll drop the argument. At least we fixed the really strange inconsistency (where it was sometimes ok to do that and sometimes not, depending on whether any *OTHER* parameters in the dummy were deferred). "the" -> "a" in note 12.19.5. I rewrote the note 12.19.5 to eliminate the Irish Bull. (It formerly implied that dummy arguments get type parameter values from the actual arguments by pointer assignment). Section 13: All the other intrinsics that have more than one form of argument list are described in a single section, with the argument list forms shown using "or". Looks like this one could be done the same way without too much difficulty. Did that instead of making 2 different sections. I probably would have missed it if Dick hadn't recently asked a question that had the exact reference in my mind, but there is a place (7.1.6 in the definition of specification inquiry) that refers to the array inquiry intrinsics in 13.12.15. Thus, moving the allocated intrinsic out of that 13.12.15 affects 7.1.6. But as it turns out, the effect is a simplification, because 7.1.6 formerly had to make an exception for allocated. Now that allocated is no longer in that section, the exception is no longer needed (and makes no sense). So I deleted the "other than ALLOCATED" from the definition of specification inquiry in 7.1.6. [306:35] Seems to me that the original was ok here. (It is required to be an array, so the existence of allocatable scalars is irrelevant). The new version would also be ok, but I left the original for consistency with UBOUND and SIZE, which have the same words. (If we did the change it should be in all 3 places [436:1-10] Its not new to this paper, but as long as my attention is drawn to it, the statement in C.11.1.4 about automatic arrays and and allocatable variables being "major advances" seems overblown, inappropriately self-congratulatory, and dated. (Presumably the "major advance" refers to Fortran 90 being an advance over f77 in this regard, though the words don't say that). I toned it down to a less sensational form of "Two features useful for...are..". Deleted some commas. paper 99-108r1, initial/final Deleted several underlines used for emphasis. When we emphasize a word, we use italics, but we do that pretty rarely. 6.3.1.1.2 "is" -> "becomes" twice. I've not done much editorial work on this paper, but this one seemed easy (and important). The point is presumably to say what happens, not to describe a state that already exists. There may well be other cases like this. I didn't study - just fell over this one. 6.3.2.1 I don't like "If the type of the object is an intrinsic type". Too many words. Changed to "If the object is of intrinsic type". Likewise for derived. I might have missed other cases/ 6.3.3.1 "follows." -> "follows:" "A process is permitted" -> "A processor...". Presumably a typo. 42:5+ Some of the stuff here was moved around by another paper. I put the new stuff where it seemed to fit best. "shall not be omitted" -> "shall be specified". This sentence had too many negatives for my taste. No hyphen in nonoptional. "element" -> "elemental" (typo). 4.5.1.5. While looking at 4.5.1.5, I made an unrelated fix in its next to last para. I sort of doubt having a single deferred procedure binding is intended to force extension types to completely respecify the bindings for all inherited bindings. I presume it is only the inherited deferred bindings. So I added the word "deferred" to make the sentence say this. In related minor edits to 39:10-13 and 44:17-25 (discussions of default initialization in 4.5.1 and 4.5.1.2). Not directly from this paper, but I'll take the opportunity for further cleanup. Now that much of the material has been moved to 6.3 (where I agree it works better), it becomes painfully obvious that these two paras don't say anything different. The one in 4.5.1 is the one that looks out of place, since 4.5.1.2 is a subsection specifically on this subject. I deleted it. The first sentence of the para in 4.5.1 was the definition for "default initialization", I changed the first sentence of 4.5.1.2 to use the term "default initialization" instead of "default initialized" and bolded it. The phrase "is default initialized" was a bit awkward as a verb anyway. Although I don't think it necessary, I copied the second sentence (about not implying SAVE into 4.5.1.2). The third sentence is also not necessary, being just an affirmative statement that there is not a requirement for something. Perhaps more of a note than a normative statement. And indeed, almost the same words already appear in the note in 4.5.1.2, so the reminder is not lost. I agree with Kurt about the confusion of terminology between "component initialization" and "default initialization". A grep revealed that the term "component initialization" appears nowhere except in the title of 4.5.1.2, so I changed that title to "default initialization for components", a phrase that is used. 93:10+ The proposal note says that it really means "must" because it is an implied requirement rather than a direct one. The ISO directives don't say anything about direct versus indirect requirements. They say not to use "must" to express requirements. I changed it to say "is not allowed", which is listed as one of the acceptable alternatives and reads a bit more smoothly than "shall not" here. Also changed "since" to "because" because time is not involved. And used the "are not allowed" instead of just "do not" after "sequence types." Although it didn't call it out as such, the paper appears to resolve issue 7, deleting the whole area around and including it. Since issue 7 was about an inconsistent duplication or material, I guess this constitutes a resolution. paper 99-110r1, formatted stream i/o, with the following changes 168:21+ Since we never once use the terms "formatted stream file" and "unformatted stream file", and since the definitions follow what you'd intuitively expect, I don't see a pressing need to define them here. Perhaps the sentence was just intended to introduce the fact that the properties of a stream file are significantly different depending on whether it is formatted. I substituted a sentence saying that. 168:26 The old wording was almost identical to that for direct access. But I changed it as directed. Added a "subsequent" (so that it doesn't invite the question of what file storage unit it is that precedes the first one). 168:31+ We already said that stream files consist of file storage units, so it seems odd to repeat it in quite the same terms here. Instead, addded "of the file" and "in addition to its stream structure" in the next sentence to perhaps elaborate on the point without just repeating it. 168:31+(3) "records" -> "file storage units". Since we have defined that the file consists most fundamentally of file storage units, thats the better way to express it here. The records are composed of file storage units, so the statements are really equivalent. 168:31+(4) Add "called the position" as was done for unformatted stream. (The definition for unformatted stream doesn't automatically apply here). Also added "in the file" just to avoid pointless differences - it reads ok either way. 168:31+(4) "processor-determined" -> "processor dependent" as suggested by Henry. (The hyphen removal by me). Was a distinction meant here? I can't recall myself whether there is supposed to be some distinction between those terms. (If there is, it must be subtle). I'll try "grep". Looks like the only instance of "processor-determined" is one in annex C, which suggests that one is inconsistent. Therefore... 418:26 in C.6.4: "processor-determined" -> "processor-dependent" 169:35-37 The changes in this paper make all the stuff about "highest-numbered position" irrelevant for unformatted stream access, insomuch as no backtabing is allowed. The highest-numbered position is now always the current position. Simplified accordingly. 169:41 "A" -> "An" 169:42+ Reordered to put the condition about being a formatted stream output statement first for a little more parallelism. Also "highest" -> "highest-numbered". 170:5-6 Made the last sentence a separate para to separate it from the stuff talking about non-advancing. 181:27+ "INQUIRE(POS=) => "the POS= specifier in an INQUIRE statement". Since INQUIRE(POS=) isn't a proper form for an inquiry. Also used "either" to avoid repeating the "shall be equal to" bit. And added a "previously"; I suppose it should be obvious, but just in case. 213:32 Because we are talking about things that can also happen when processing data edit descriptor, rather than ways that file positioning can also happen, reverse the phrasing to say "... may also cause file positioning" instead of "file positioning may also be caused by...". 218:43+ Put this after the note instead of before (because the note relates to the preceding material). Henry's "several" -> "more than one" also looks like an improvement. Simplified to "the intrinsic function reference ACHAR(10)" instead of spelling out the bit about its argument. Used ";" instead of and to more clearly separate the newline from the non-newline clauses. Although i.e. is perfectly fine English (or Latin) and I use it myself, I wonder whether we should be using it in the standard? Looks like there is only one other case - in note 12.37. I removed both that one and this proposed new one. "which" -> "that" All processors can represent the result of the intrinsic function reference ACHAR(10). See the description of ACHAR. If the ASCII character is not representable, then ACHAR(10) returns something that is processor-dependent. That processor-dependent value is, by construction, representable (since it got represented). What is in question is whether the processor can represent the character at position 10 in the ASCII collating sequence. If my translation isn't adequate, then we have an unresolved issue here, because the proposed phrasing doesn't make any sense to me. Added some commas. paper 99-112, additions to character set, with the following changes I moved around a few of the entries in the table to try and keep simillar things together. The order is pretty arbitrary. paper 99-113r2, c_loc, with the following changes Also found (and changed) ISO_C_TYPES at 377:29, 379:3, 380:4. Directions said to add material "at the end of 16.1 (after 377:32)." The list of provided names (not functions) does end at 377:32; added c_loc to that list. However, that location is neither particularly near the end of 16.1 nor a plausible place to add the sentence about c_loc. I added the sentence at the actual end of 16.1, at 378:49+. Also reworded it to "The C_LOC function is desccribed in 16.2.3." I didn't like the "is also provided" wording. Not really related, but while in the area, I added "Its use is described in 16.2.2." to [378:27] about C_PTR. Otherwise I was left wondering what on earth it was about. Just saying that it was a derived type or a type alias didn't tell me much. All the other things in ISO_C_BINDING had enough information in that section to give me at least some clue. I assume that the proposal to add the new c_loc section as 16.2.3 refers to the numbering after the changes from paper 99-118r1 instead of the numbering in 99-007. I had first assumed that the numering referred to 99-007, insomuch as the paper didn't mention otherwise. But I couldn't figure any rationale for that placement. I had started to say that I was going to add it elsewhere before I noticed that one of the plausible places was ending up as a 16.2.3 after the 99-118r1 change. You know, it probably took me at least 10 or more times as long to figure this out as it would have taken for the paper to actually say it. The editor would greatly appreciate a little more care being given to describing edits. Two out of the 3 edits in this paper were described confusingly enough that I had to deduce where the author probably intended them to be. If it isn't worth the author's time to describe them accurately, then it isn't worth 10 times that much of my time to deduce the intent. (The instruction to do the global replace on ISO_C_TYPES was fine - that's easy enough without needing a complete list). The proposed section title "C_LOC The C address operator" doesn't parse sensibly. It would need some kind of punctuation between the C_LOC and the rest. Furthermore, the "The" shouldn't be capitalized unless it is the first word of the title. I eliminated the "C_LOC"; I half wonder if that wasn't the intent and that the C_LOC might have been an accidental remnant of some other thought for a title. I'm dubious of saying that "C interfaces are *PRIMARILY* defined in terms of "addresses"." Changed to "Many C interfaces are defined in terms of "addresses"." "C_LOC" -> "The C_LOC function" to avoid starting a sentence with it. I don't think one "calls" a facility. If its going to be "call" lets describe it as a function. As long as it is "facility", I changed "in calling" to "with". The layout looks a lot like it was modeled after the intrinsic procedure definitions in c13, with some diferences. I followed the c13 layout more closely. Description. Returns the "C address" of the argument. I didn't like "provides" as a description. Class. Inquiry function. All the corresponding entries in c13 include the word "function"; I don't see a reason for gratuituous inconsistency. Omitted "A" in result characteristics. The phrase "target C processor" appears to be in a slanted or italic font in the paper. I'm not sure what this is supposed to indicate. The usage doesn't match anything that I know we use a special text convention for. I set it in normal font. "C9x" -> "the C standard". We already have an unresolved issue that says the term "the C standard" needs to get defined in 1.8 and used elsewhere. The typography of the example left me uncertain what was intended. The box around it suggests that it might have been intended as a note, but it doesn't look at all like any layout used in other notes - the sample code being in a right column, with the word "example" on the left. That style is closer to the style used for normative example subsections in c13. But none of those have actual code samples. I eventually went with the note, but changed the layout and added a actual introductory sentence rather than just the word "Example". paper 99-114, unresolved issues 71 and 84, with the following changes Also found a case of restricted-type-spec on 61:18 paper 99-115r1, J3 notes in c9-10 Issue 28: Deleted the "for an internal file" (twice) because this is in a list already specific to internal files. Issue 4: Deleted "Note that". "since" -> "because". "only exist" -> "exist only". Deleted 2 commas. Issue 69: "All" -> "The". Hyphenate zero-sized, derived-type. "are ignored and not considered to be" -> "do not contribute to the" I deleted the statement proposed for addition in 9.5.4.4 that "The next item to be processed is called the next effective item" because it wass incorrect. Its not the next item to be processed; it is the next *EFFECTIVE* item (there being a difference, since this is part of a discussion of list items which may be arrays, etc). But if I add the necessary "effective" to the sentence, it reads "The next effective item to be processed is called the next effective item", which is true, but not something that I can imagine saying, at least not in those terms. If there is something else that needs to be said here, let me know. Issue 3: I deleted "and the IOSTAT and ERRMSG variables are set to values determined by the WAIT operation." This was right after saying that steps 4-8 are skipped. Step 9 is setting the IOSTAT and ERRMSG variables. Saying that this happens as part of step 3 and then (again?) as part of step 9 is confusing. I suppose this might have been an attempt to point out that the values used are those of the WAIT operation, but if so, the relationship between what step 3 and step 9 say is not clear. (Perhaps step 3 sets them to one value and then step 9 resets them). I don't think that clarification is needed here (it wasn't the point of the unresolved issue). If it is needed, then the exact words still need some work. Hmm. See remaining issue 3 for more. "4-8" -> "4 through 8" Issue 23: Reworded whole para the last edit. The sentences were a bit awkward before, and more so afterwards. The scope of the "if" part was a bit unclear. And it wasn't explicit that the edit descriptor talked about was from the parent data transfer statement. Plus, part of the para still sounded like a requirement on the program. Issue 70: "Since" -> "Because". I was taught to use "since" only in its meaning of "after" in technical writing. Otherwise, it can be misinterpreted, particularly in translation. Issue 25: Added "the value". "current rounding control in effect" -> "rounding control currently in effect" "from" -> "than". The "from"->"than" question is tricky here. Strunk and White specifically mention "from" as preferred with "different". Both my ear and the dictionaries I checked mostly agree (excluding the allegedly British use of "to"). But this case still sounded wrong to me. Further checking in a Websters unabridged said that "differently" (the adverb form) takes "than" when a clause follows. In this case, the clause is perhaps hard to notice because its verb is implied rather than explicit (there is an implied "behave" at the end of the sentence). So I conclude that the "than" that sounds best to my ear here is correct. (Guess I could have relied on the ear, but that has occasionally led me astray in other cases). Issue 31: I don't think we mean to use "decimal symbol" in logical editing, so I didn't change that case (in what was 10.5.2, now 10.6.2). Indeed, I'd say the old words were poor. This should not have been described as a decimal point in the first place; its use here has nothing to do with decimal. It should just be called a period in this context. (Table 3.1 gives both names for that character). Fixed to do so. I was struck by the difference between how the proposed text in 10.5 and in the glossaty described the decimal symbol. The normative text said it was after the units digit, whereas the glossary said it was before the fractional part. Both seem equally true (given an appropriate interpretation of what they mean when the units digit or fractional part don't appear), but it seems odd for them to differ. I split the difference and used neither form. Instead I said that it separates the whole and fractional parts. If this is disliked, either of the other 2 wordings are ok by me, but I think the same wording should be used in both places. Added an "a". I don't offhand see any other cases of section xrefs in the body of glossary entry. (Not quite sure why not...and there are syntax number xrefs...but I guess I'll go with the existing style). So I moved the section xrefs to the parenthesized list as with the other glossary entries. Added descriptions of the "." in the (new section numbers) 19.6.1.2.[2-4] descriptions of E/D, EN, and ES. This is the only missed place that was obvious to me. I assume I'm correct that we do want the decimal edit mode to apply there? I'd be surprised if we didn't....but then I've been more surprised at other things before. paper 99-116r1, enums I'm concerned that it might be confusing to use the term "associated with" to describe the relationship of enumerators and the enumeration, since we define several types of association (and this isn't any of them). I couldn't come up with a word that I did like, so I reworked the sentence instead. Also, since we just defined an enumeration to be a type alias name, then we can't say "the type alias name of the enumeration". That reduces to "the name of the name". "The enumeration is treated" -> "The is an enumeration, which is treated" Otherwise, we never explicitly say that the type-alias-name in the bnf is the enumeration. One could guess from context and because we did say that an enumeration is a type-alias-name, but it needed to be explicit. "present" -> "specified" (several times). I prefer to reserve the term "present" for optional arguments...not that we've been 100% consistent about that. But in these cases, "specified" works just as well (and was already used some of the time). Various wording problems relating to kind type parameters: The term "type kind" appears nowhere in the standard; "kind type" appears only as part of "kind type parameter". A kind doesn't interoperate with anything (its the integer of that kind). Reworded around all these. "companion processor's integer type which the companion processor uses" -> "type the companion processor uses". The longer phrase seems redundant and harder to read. "the same values" -> "the same enumerator values". For the first (2) and (3). We already said what the kind is used for; just define here what kind is selected in these cases. Don't re-say that it is the kind of the enumerators and enumeration. Just talked about "an integer of that kind" instead of the bit about "characterize a representation". "An enumerators" -> "An enumerator" "as if" -> "as if it were". "and" -> "and with" I don't think we need to mention that in the 2nd (3) that the expression described is a constant expression. (It is true, but so what?) Simplified to "its value is the result of adding 1 to...". "which" -> "that" "must" -> "is required to" Rephrased the comment in the note to say that the kind has to be sufficient for the values 4, 9, and 10 (that being the way the normative text describes it), rather than talking about the largest value (and thus avoiding the question of defining "largest"). Added a comma. paper 99-117r2, interop glossary, with the following changes For the "C9X placeholder", refer to "the C standard" like the note in 1.8 says we are going to do. Likewise, refer to "the IEEE standard" like we already do extensively elsewhere (mostly c15). Shorten "A technical term defined in C9X. See section xxx of that Standard." to "A technical term defined in xxx of the C standard." in several places. I could add the term "subclause" before the xxx, if people think that would be an improvement (I'm of mixed opinion), but ISO will probably gripe if I use the term "section." Most (but not all) of the existing glossary entries have section (I mean clause) xrefs. I see that there are none for any of the new entries in this paper. This does not overly bother me. I just want to make sure it was intentional. If someone was assuming that I'd come up with appropriate xrefs to add, then I compliment them on their optimism. Oh. I see that there are 2 xrefs, but that they don't follow the glossary style. I put them in the right style. "This" -> "It" several places. I am not aware that we use a word "datatype". I changed all instances to "data type". And I then italicized "data type" per the first para in the Glossary. "the" -> "a" several places. "derived datatype" -> "derived type" because that's the way we always seem to use it. In the "companion processor" entry, I'm not sure that we should be using a phrase like "most likely". But I'd guess it to be accurate and it is just in an annex, so I'll let it pass. The paper uses a different punctuation style for each of the 4 occurances of one construct. Impressive. Its the construct where we give a definition in 2 forms, one perhaps a bit more formal. For "companion processor", the definitions are separated with a semicolon. For "INF", we use a comma (and capitalize the second one, which seems inconsistent with a comma). For "rounding modes" we use a period. For NaN we use a period, but put the definitions in the other order just to be different. I'm not certain what is really best here, but I went with the semicolon. "which" -> "that" in the INF definition...unless you meant to imply that an IEEE floating point operation *ALWAYS* yields a result outside the representable range. (Yes, that is the implication with "which" - the distinction is sometimes important). In NaN, "a result" -> "results" and "is" -> "are" to agree with "values". "which" -> "that". Hyphenate "domain-specific". paper 99-118r1, procedure interop A bunch of comma changes thoughout. Mostly deleting incorrect ones. Someone is a bit overenthusiastic about using them to try to fix up sentences that are hard to parse...not that this iss a rare failing. 2.5.10: Boldened "companion processor" in the second sentence instead of the first. The bold indicates first definition, not just first use. The second sentence reads like a definition; the first one doesn't. Hyphenate "processor-dependent". A procedure may be defined by a C function, but I don't think it proper to say that the definition *IS* a C function. We don't use terminology like that for Fortran subprograms. You'll see words about a procedure being defined by a subprogram, or that a procedure defines a subprogram, but I don't think you'll see anything saying that the definition of a procedure *IS* a subprogram. Correct me if I'm wrong. Suppose I could be, but it didn't sound quite right. Particularly when "definition" is used twice in the same phrase as in "The definition...is referred to as the C function that defines". So I reworded this bit a little. Speaking of terms used twice in a sentence, it doesn't make sense to talk about an effect having an effect. Fixed. Also put that sentence into present tense. "but need not" at the end of a sentence seems like an incomplete phrase. It might be legit, but I don't like the way it reads. Deleted it and changed the "may" to "might or might not". "The" -> "A" in the note. Moved the sentence about selecting among processors from the last para of 2.5 up to the end of the first para. It had no obvious relation to the other sentence that was in the last para. Also reworded the sentence a bit. I didn't like the "might select" bit; instead added a condition about "If there is more than one companion processor". [39:37] While on the subject, changed the "not" to "neither" to make the sentence grammatically correct. (Not a new problem). "nor" does not go with "not". (See Strunk & White entry for "nor" under "Words and Expressions Commonly Misused"). 5.6: Factored "statements" all the way out of the "or". I'm not sure why we'd pointedly group SEQUENCE and BIND(C) separately here, as the proposed wording did. 12.2: "if any" is almost always superfluous (and just makes sentences harder to read). Omitted it. Note that the same sentence has no such phrase after "dummy arguments", although there might not be any of them. 12.4.1.2: I still had several problems with the wording of the third para of 12.4.1.2, but the suggestion in 99-118r1 gave me the clue to how to do what I'd consider far better wording. The first 2 sentences in the para are fine. I've long had a problem with the third sentence. Its antecedants are non-existent and its generally hard to figure out what it is contributing. Notably it talks about "the restriction", but there is no applicable restriction that has yet been defined. One is supposed to infer that it is saying there is a restriction simillar to the one for the scalar case, but with some differences. But it doesn't actually say that. After a fair amount of study, my conclusion is that this third sentence is a (poor) attempt to say the same thing as the last sentence added to this para by 99-118r1. Saying it once seems enough, and the words in the last sentence are far more precise and clear. So I just struck the third sentence. The last two sentences of the para were proposed to be replaced by 2 sentences in 99-118r1. I agree the new versions are an improvement, but I think we can do better yet. The first of those 2 sentences says nothing that isn't already said by the 2nd para of the section. The 2nd para says (paraphrased and omitting irrelevent stuff) that default character length parameters need not agree unless the dummy is assumed shape. We are now just repeating this lack of requirement, going into more detail about what it is that they don't have to agree with. This seems pretty pointless. And for all its detail, I see that it still misses a critical point and thus invites an interpretation request - it fails to mention the exception for assumed shape; thus it might be interpreted as saying something different that para 2. Unless this is actually supposed to be saying something that para 2 doesn't say, I propose just deleting it (and I did so). If it is supposed to say something different, I'd sure like to know what. Thus para 3 becomes much simpler by deleting 2 of its sentences. I reworded the last sentence to clarify exactly how it applies and what cases it applies to. Its reference to 12.4.1.5 is great; that's where all the ugliness is defined, so just referencing that instead of trying to repeat it here makes this much simpler. That was the key I was missingbefore. This resolves issue 113. Issue 114 - Deleted it, but for a completely different reason than mentioned in paper 99-118r1. The edits in the paper do absolutely nothing to address the issue. All of the edits were about default character, whereas the entire point of issue 114 was non-default character kinds. However, issue 114 was just wrong in the first place. I dunno where I got the idea that the practice mentioned was allowed for non-default character; the 3rd sentence of 12.4.1.1 in f95 pretty explicitly says otherwise, as does a simillar sentence in f90. Added the new issue at 257:15 instead of 256:15. [263:39+] There is no such bnf term as scalar-default-char-init-expr. The scalar part is ok because 1.6.3 has a rule for that. For the rest, we can work from either default-char-expr or char-initialization-expr and add the missing qualification as a constraint. I went with char-initialization-expr, with the default kind part as a constraint. Choose this because I thought that being an initialization expression was more fundamental here than being of default kind. Also deleted the superfluous close bracket. [263:41+] Used "specified" throughout instead of randomly switching between "specified" and "present". Did this in the existing constraint there also. Also changed to use a symmetric form of these constraints. I.e., Phrase them as "A prefix shall not specify both X and Y" instead of "if X is present, Y shall not be specified". I took out the condition about "If BIND is present" from the constraint on abstract interfaces and dummy procedures. If BIND is not present, then there is no place for a NAME=, so the condition is moot. The condition is just that there can't be a NAME= bind-spec... Also, a dummy procedure does not have a function or subroutine statement. Its the interface body for a dummy procedure that has such a thing. Just "The NAME= ". Likewise for BINDNAME. "BIND" -> "The BIND " just to avoid it starting a sentence. In the note. Deleted "For example". And there is no referent for "the function" so I started the sentence with "If a procedure has" and changed "the function" to "the procedure". Added a "then" to make it more clear where the condition ends. [268:7+] added "with the BIND(C) attribute" after "procedure" instead of having the "if" clause at the end of the first para. Lets not refer to prefix-spec here. That is too closely tied to syntax. Just talk about the BIND attribute. After all, if BIND(C) is added to, for example, PROCEDURE statements, I doubt it is going to be as a prefix-spec. (Except kept prefix-spec for the ENTRY stuff; harder to avoid it there when talking about subprograms). Just "expression in the NAME= specifier" instead of the detail that it is after it. "The case of letters is signficant" instead of "The case is significant for any letters". "function" -> "procedure" before "using lower case letters". Otherwise, I don't know what the antecedant of "the function is"; we've been talking about a procedure, which could be either a subroutine or a function. Added a "then". In the note in 12.5.2.6. Added "sample" after "following". And quoted the binding labels listed in the introductory sentence; I think it important to emphasize here that they are character values, not Fortran names. Used an "END FUNCTION" instead of "END SUBROUTINE" to end the function in the note. Rewrote the second half of the sentence after the sample code in the note. Made it a separate clause instead of misusing a comma. More significantly, it was not clear that the "that are not permitted" modified "distinctions" instead of "names". Also, changed "names in this standard" to "Fortran names" twice. This standard does not prohibit C names from having any values that the C standard would allow; but the former words could have been read as doing so. The point is only that Fortran names have different rules, not that Fortran is disallowing some of the rules for C names. This sentence was specifically talking about C names, and this sentence is in "this standard". Thus saying "in this standard" is not sufficient to mean that the subject must be Fortran names. Likewise talk about C names instead of "names...according to the C standard". "with regard to case" -> "in case". [268:13+] Added "either". I greatly simplified the first sentence of the last para of 12.5.3 so that I could manage to parse it. besides which, we shouldn't be talking about syntax everywhere anyway; talk about the attribute, not the syntax for specifying it. I'm assuming the useage of "can" rather than "may" is intentional, so I left it that way. [377:2-4] It seems more pertinent to say that Fortran provides a means of invoking C procedures than just to say it provides a means of specifying an interface. The part about specifying an interface is a detail compared to the basic principle that you want to be able to call them. For an introduction, one should start with the broader pinciples, not the details. So lets start out the introduction talking about calling C procedures, not just specifying interfaces for them. Note that a few sentences later, we do talk about C calling Fortran. But we never mentioned Fortran calling C - we just said Fortran can specify an interface. "for which C prototypes can be written" -> "that can be described by C prototypes". I think this phrasing fits a little better with the rest of the sentence, though its not a big distinction. Made the sentence consistent in number. (We had "procedures... even if the procedure") Said that the kind type parameters in ISO_C_BINDING are for representations compatable with C types. Otherwise, its not clear what this has to do with C interop. Just saying that it provides kind type parameters isn't enough to make the connection; nor can we count on the module name to say this. And I don't think the mention of ISO_C_BINDING is appropriately placed between the sentences that mention Fortran calling C and vice versa. I moved it to the next para, where other issues of type are discussed. Conversely, I moved the discussion of global variables up to the first para. It seems to me that the highest level things to mention are procedures and variables; those belong in the first para. The fact that we need type parameters, derived types, etc. in order to declare compatable procedures and variables is the next level detail and reasonably goes in the 2nd para. There is no antecedant for "these facilities", so I reworded that to "Conversely, There is a means...". We appeared to get bored with the phrase "defined by means of" and randomly changed it to "written by means of" in one case. As boring as it is to use the same phrase all the time, I think it better to do so. I think one "defines" a derived type rather than "creating" one. Since 4.7 does not use the term "enumerated type", it seems inappropriate to do so here. Indeed, 4.7 fairly carefully avoids calling an enumeration a type, recognizing that it is just a type alias instead of a distinct type. [379:1+] Definitions are best phrased in the singular. Did so. "when" -> "if" unless you mean to imply that interoperability is a function of time. Hyphenate "null-terminated". "that" -> ", which". (The opposite error is more common, but "which" is right here). "last valid element value" -> "last valid element". I'm not sure how the null character indicates the last valid element value, unless you mean the null value itself, in which case we know what that value is going to be without even looking at the string. Its also a little unclear to me which element would be considered to be the "last valid one." Is that the (possibly non-existant) element before the null character, or is that the null character itself. Oh well, its just a note and that detail doesn't actually affect the message, so I'll let pass the fact that its a bit vague. I'm not sure that "to argument associate" is a verb form that we use elsewhere, but I suppose its meaning is clear enough. "a simple matter" -> "possible". I don't think we need to comment on the simplicity. 380:32 "types" -> "type definitions" Yes, this is adequate. I didn't think it needed much - but it did need something. I hadn't even thought to add the note about the names possibly disgreeing, but its a good point. 382:2-20: Issue 103....after thinking quite a while. Ok. Perhaps I was just confused. I think I may be starting to get this part anyway. We don't talk directly about how to call a C function. Instead we talk about what a Fortran version of it would look like. How you could call the C function then follows from how you could call the Fortran version. I guess this makes sense. I'm still not 100% sure that its explained as clearly as it might be, but at least I can see how it could make sense. (So deleted the issue as instructed). [382:21-23,31-39] Added two "either"s. I thought that made it read slightly better - not sure why and it wasn't a big difference. To answer the question, yes, this is much more clear that the previous version. I wasn't being snide when I said that I couldn't parse the previous one - it wasn't just that I thought it hard to parse or saw some error - I actually couldn't figure out what it was saying. Now I can. I put the new note at the end of the normative text added. The phrase "a C array of the element type of the C array" doesn't make much sense to me. At the very least, we need to distinguish the "original" C array just like we did for the Fortran one. I changed it to "a C array with a type equal to the element type of the original C array". Let me know if that's not a reasonable translation. [383:24] I made this a separate numbered item in the list instead of tacking it onto the same item. paper 99-119, issues 73, 77, 80 [62:17-18] I'm not quite sure why the choice to use the non-bnf terms here, when an almost identical constraint a page before uses the bnf terms. I do understand why "assumed or deferred" goes with the non-bnf terms, while "a colon or an asterisk" goes with the bnf. I kept the bnf, changing to "a colon or an asterisk" just like at 61:23, so that the two constraints are similarly phrased. If I missed some subtle reason why they should be different, tell me. [65:38-40] Kept the "nonkind" modifier for type parameter value. I certainly hope the edit wasn't supposed to imply that kind type parameters need not be constant. Then put "array bound" first because that seems less prone to misreading (so nobody thinks the nonkind is supposed to modify both things). [65:41] "a" -> "an" [67:42] Another "char-len-param-value" -> "type-param-value". [122:40+] The cited place to add a new paragraph is in the middle of a sentence. I did the insert at [123:8+] instead. [123:35+] The J3 note is numbered 132. (And I added some extra words to it as detailed elsewhere). [123:36] "a" -> "an" paper 99-120, misc fixes, with the following changes [41:33] Superceded by paper 99-121 (which includes a comparable change). Added a comma. Added an "an". paper 99-121, syntax changes in derived type def, with the following changes After consulting with the author, kept the type-param-def-stmt bit directly in the syntax for derived-type-def instead of in the lower level data-component-part. This seems more clear because the type parameters aren't particularly associated with the components; they can just as well be used in the type-bound-procedure-part. In Van's words, "This doesn't change the syntax -- it just improves the exposition." Since this paper reorders some things in derived-type-def, I correspondingly reordered a few of the lower-level syntax rules and constraints in that section, so that the rules subsidiary to derived-type-def are still, presented in the order that they are mentioned in derived-type-def. No changes other than reordering. [47:31] Delete the first "statement". (The type definition has a data-component-part, but the type definition statement does not). [48:5-6] This edit would leave the phrase reading "PRIVATE statement in a data-component-part instead of a binding-private-stmt", which doesn't quite make sense. (I might say that a PRIVATE statement is a binding-private-stmt, but not that it is in one). I changed it to be more parallel by saying "PRIVATE statement that is in the data-component-part instead of the type-bound-procedure-part". And changed the binding-private-stmt bit on 47:42 to refer to a PRIVATE statement in a type-bound-procedure part, so that all the references to PRIVATE statements in this area use simillar terminology. [340:37-38] I notice that although this paper slightly improves the wording of the sentence in question, it doesn't actually address the detail that the sentence is incorrect (unresolved issue 62), but I suppose that's a separate issue. Unresolved issue 62 left as is. [42:4-5] "procedure name specified by procedure-name or binding-name" => "procedure-name". This constraint is not meant to apply to binding-name unless the "=>" is omitted, and thus the binding-name is also used as the procedure-name, but the proposed wording didn't make that clear. We do have words saying "If =>procedure-name is not specified, it is as though it were specified with a procedure name the same as the binding name." With these words, which are there anyway, my simpler constraint covers everything without introducing the extra confusion about possibly applying to the binding-name in other contexts. "it" -> "the procedure". Otherwise, it looks like PASS_OBJ is the antecedant, which wouldn't make sense. "proc-interface-name shall have..." => "the interface shall have..." An interface may have dummy arguments; the name of the interface does not. The bnf proposed allows the syntax PROCEDURE () whatever => NULL() but gives no interpretation of it. The comparable syntax in a procedure delaration statement would be declaring a subroutine with an implicit interface, which wouldn't seem appropriate here (since we require an explicit interface in all other cases). I'm assuming that the optionality of the proc-interface-name is a typographical error (from copying the syntax from a context where it was optional) and that if you have the parens here, you are required to have the proc-interface-name inside of them. Note that the whole "( proc-interface-name )" is still optional - I just deleted the extra optionality of the part inside of the parens. More a matter of perception than objective measure (so feel free to override me), but I feel it is slightly clearer to keep the bnf term . So I did. This allows the "or" to be a simple choice between "procedure-name or NULL()" rather than having an "or" that repeats the whole syntax of the PROCEDURE statement, including much that is the same. It elimination of this duplication actually ends up with a result that is more concise even with the extra bnf definition. The only advantage I can see to the larger "or" is that it shows in the bnf that you may only have a proc-interface-name with a NULL() binding; but that is said explicitly and clearly in the constraint anyway. (I slightly changed the constraint wording to fit better with this form, but could have gotten by even without that change). I almost backtracked on this when I realized that the constraint didn't cover the case of having an empty parens... before I figured out that it wasn't intended to allow that possibility anyway (see my comment in the para preceding this). Reordered constraints to correspond. Added some commas.