J3/01-348 Date: 1 Oct 2001 To: J3 From: Richard Maine Subject: Edits incorporated in 01-007R3 This paper describes the changes in J3/01-007R3 relative to the previous f2k draft, J3/01-007R2. All page/line references are to J3/01-007R2 unless otherwise noted. The change bars in 01-007r3 are relative to 01-007r2. This includes edits from papers (all 01-) 264r2, 265r1, 266r2, 267r2, 268r1, 269r1, 270r2, 273r2, 279r2, 282r2, 283r2, 284r1, 286r2, 298r1, 299r2, 313, 314r1, 315r2, 318r1, 319, 320r1, 321, 322, 323r1, 325r2, 326, 327, 328r1, 329, 331r1, 332r1, 333r2, 335r1, 336r2, 338r1, 339r1, 341r1, 343 typo/editorial fixes from an email from Bill Long [287:22] "he" -> "the" [335:41] "further to" -> "beyond" typo/editorial fixes from some emails from Van Fixed anomalous font sizing in index. Non-bold page numbers were in a larger font than the other stuff. Don't know why - probably just that nobody noticed before. Fixed index entry of 69-??? for attribute. I put the end of this range at the end of subclause 5.1.2 (including its subclauses), as it was in f95. This probably got lost when the subclauses of 5.1 were alphabetized. Likewise put the end range for "type declaration statements" and "statements:type declaration" at the end of subclause 5.1 (and its subclauses). other typo/editorial fixes [258:6-7] delete "or with...construct". This is just redundant. The END statement is an executable construct, so if there are no other executable constructs, then it is indeed the first one. It is silly to say "the first one unless that is an end statement, in which case we do the end statement", which is pretty much what this says. I almost wrote this up as an unresolved issue, but decided to just fix it instead. paper 01-264r2, with the following changes [24:20+] "statement labels" -> "the labels" (said "statement label" in the phrase right before - and this makes it fit on one line). It is redundant to specify that a type has to be an extension of another type and also that it has to be extensible (all extensions are extensible). Reworded 151:2 to simplify this. 156:22 - did for second occurance on the line. "contains" -> "has" (I prefer to avoid using Fortran keywords in unrelated contexts where practical. It isn't practical to avoid words like "if"; but "contains" has plenty of fine alternates; "has" even has the advantage of being shorter). paper 01-265r1, section 1 with the following changes Reworded the note 9.3 replacement. I didn't like the phrasing "an example..is that..". Also, a processor isn't required to disallow reading from printers (and printers often allow reading these days), so make the phrasing indicate this as just a possibility (which is the point anyway - that a processor might do this, not that it necessarily would). [162:34] also inserted "by" after "represented" [164:24,46-47] I personally think the qualifiers here are getting pretty ludicrous; this is a pretty big paragraph for such a trivial concept. There was already a previous edit that added qualifiers to this para (thus all the "might be permissible" stuff instead of the "is permissible" as used in the corresponding direct access para). I find the abundance of qualifiers here redundant and distracting. Admitedly, this new one is more explicit than the "might be" ones, which don't give much hint about what condition they refer to (I never did really like them because of that). I'd propose changing the "might be"s back to "is"s, on the theory that the new phrase covers us for the paragraph. But I didn't do so. I note that the result comes perilously close to saying "if it is possible to position the file, then it is possible to position the file" (particularly the formatted case). I view the bit in 9.5.1.10 as just an explanation of how some operations might not be applicable to some files, much like the first para of 9.10. We don't feel obligated to preface every paragraph about reading from a file with "if it is allowed to read from the file". [172:1-] "may" -> "might" twice in the note. No permission is implied. [181:11] Good catch, but wrong fix. We don't really don't mean the "if" part here at all - just the "only if". Writing "if and only if" makes the error more explicit. (We don't really mean that all other restrictions are lifted as long as this one is met - i.e. that we could read into a target that was also being used for something else in the same statement). I started by changing "if and only if" to just "only if", but that was subject to the usual misinterpretations of "only", so I reworded to use "may not appear...unless" phrasing. [184:33] Wow, you have sharp eyes (and you were correct). [187:34] Or even better, just deleted the "as". [195:4] The two phrases in question are not equivalent, but perhaps the cases where they differ don't matter because they are otherwise ruled out. (The main case that occurs to me is when the file position is indeterminate...in which case backspace is probably disallowed somewhere.) I did the edit as in the paper; I suppose its probably ok. [197:25] Also deleted "the" before "variables". And I was tempted to delete the "(if any)", but I resisted because someone would probably object. I rarely think that "if any" is appropriate to say. Might just about as well have said "if any" after "all of the inquiry specifier variables"; I don't see that it is actually required to have any of them (the inquire-spec-list could consist of just a unit= or file=). (P.S. No, I'm really not proposing to add another "if any"). [202"15-16] Used "has" instead of "contains". In addition to my general reluctance to use "contains" when not referring to the keyword of that name, I think "has" reads better here. paper 01-266r2, section 1 with the following changes [208:27-28] Omitted "which is" from the parenthetical phrase. Not sure I like the phrase at all (particularly as what is described immediately below is the repeat factor instead of reversion), but I put it in anyway. I also don't like using commas with 2-item lists, but I admit the sentence is hard to read without the comma, so left it in. [211:37,38] Also added "sign" after "plus" and "minus" here. If we are going to do this, might as well be consistent, which brings me to a question I didn't do anything about... If the characters in questions are never to be referred to as just "plus" or "minus", should we not correct table 3.1? Every other character name in it appears to be acceptable as a noun form (and one of them even includes "sign"). This didn't seem important enough for an unresolved issue and it wasn't something I felt ok to do on my own (in case the names in that table correlate to names in some other standard), so I'll just note it here. [212:38] Did the same F replacement as in all the simillar cases. The edit marked as [213:30] is presumably [213:32]. [216:18] We usually say "on output" instead of "during output". Its more precise anyway. We don't mean to imply that if we are in a uddtoip for output that there is no effect on possible internal input statements because it is "during output". [219:25] Having just noted the vagueness of "during [in/out]put", I see the same thing in the original (and unchanged) text here also. Changed both references from "during execution of an [in|out]put statement" to just "on [in|out]put". [219:46-47] Reworded to use the phrase "which one of them" instead of "which one of the two nearest representable values"; we already mentioned the bit about the two nearest representable values once in the same sentence. Also swapped the order of phrases in the sentence to read better. In the first sentence of the new 10.6.1.2.6, the xref to 9.5.2 doesn't make sense. I'm guessing it to be a typo for 9.5.1, which I've refined to 9.5.1.12 (the same xref as used elsewhere on this subject). Added two commas to first sentence in 10.6.1.2.6. Also factored out the "by"; I don't know why we had two "in"s and one "by". "In" would admitedly be questionable applied to an edit descriptor, but "by" seems to work fine for all three. 249:21 is pretty clearly a typo for 349:21 in the edit about changing xrefs from 10.7.7. paper 01-267r2 as is paper 01-268r1, with the following changes [237:31-32] "contains" -> "has". And moved the "also" to before "defines" (so that it modifies something that did explicitly appear in the preceding sentence, giving a better tie for "also"). [239:39] I presume that the "in an" refers to the case on line 38. There is also a case on line 39, but the replacement doesn't make any sense for that one. [240:23+] Some of the specified sort keys being identical, I used a stable sorting algorithm. [241:19] Unrelated additional edit while looking here. An interface body doesn't "create" an interface; it just specifies one. The only other use of the string "create" in all of c12 is in regards to creating instances of a subprogram in 12.5.2. So "created" -> "specified". [245:16+] Didn't do this. Debated putting in an unresolved issue on it, but just omitted it instead. Reraise it if you really want me to do this. This all but repeats what is said in the last para of the note that immediately follows the proposed note. I could understand perhaps wanting to move this material up earlier and to generalize it, if those are the purposes of this edit. But this proposed edit omits at least one important case and, in so doing, provides more of a disservice than a help. At it stands, the last para of the following note seems more helpful in that it covers all the cases I can think of (see it to be reminded of the case that the proposed note omits). [247:24] Agree that the "then" replaced by this edit is poor. But this edit doesn't give an adequate substitute, resulting in a sentence that is just wrong. The argument to C_LOC is not required to be a procedure at all; that statement needs qualification to be correct. I added "For such application," as a qualification; then "would have to be" fit better than "is required to be". [250:24] Did the one case on line 24. I assume the "twice" meant to also do it on line 25, but that case is made worse by the change. With the change on line 25, the "that does not have INTENT(IN)" would modify only the pointer, not the allocatable. That would make it wrong, which is worse than the minor sin of using "an allocatable" as an implied abbreviation for a variable with the allocatable attribute. I could probably have reworded to fix this, but being behind schedule, I just left it alone instead. [252:23-44] Hmm. Indeed. The wording is so much the same that this is almost bound to have been an editing error. Though I don't recall the edit, this sure looks like the remnants of attempting to move the note, but forgetting to delete the original. Makes me suspect that just deleting note 12.25 would be appropriate, but the proposed short note seems ok also, so I did it as specified. [253:1-14] The claim that "there is no reason" is simply wrong. There were certainly reasons. Whether the reasons were good enough is presumably arguable. I don't recall exactly what the reasons were, but I certainly recall that it was intentional, and on quick skim, I think I can reconstruct what they probably were. Nothing else in 12.4.0 says anything about the relationship between actual and dummy arguments; all such material is in 12.4.1, which is where these constraints formerly were. Indeed, I'd argue (and I reconstruct that it must have been the original argument) that there is "no reason" to move the material to 12.0. The only thing it has to do with 12.4.0 is that it is phrased as a constraint on R1221. If we said the same thing, but phrased as a text restriction instead of a constraint, then it would "certainly" be in 12.4.1.2 along with all the other simillar material about the relationship between actual and dummy arguments. On thinking about this, I realize that the reasons are strong enough so that I moved the constraints back, even though I had already done the edit. (But I did delete the line above them, which is needless with out current constraint syntax). If people had really thought about the question and decided that the material belonged in 12.4.0, I'd have done it, but the "there is no reason" claim convinces me that the reasons were just neglected rather than considered and found wanting. [256:32] Did as directed, but I'd think a better fix would be to delete the phrase (from both places). The phrase is superfluous (I'm sure we've established somewhere that the value of an object depends on the values of its subobjects) and the sentence is long and complicated enough to benefit from simplification. paper 01-269r1 as is paper 01-270r2, with the following changes [168:32] Leave the "The" as is. (The "particular" makes it definite instead of indefinite). paper 01-273r2, with the following changes There were two other xrefs to the former 16.1.2.4.4, which Frame did not fix up, so I had to do manually. One in section 4 I just revised to follow the moved section, which wouldn't normally merit noting here, as it is just me manually fixing what I regard as a Frame bug. But the xref in the section header of C.12.2 seemed wrong; I don't know why that was pointing to material about dtio in specific. I moved it up one level to point to 16.1.2.4. I don't think the paper actually understood the comment in the last para of the former unresolved issue 333, but it wasn't the most important part of the issue anyway. It might not have come up at all if things weren't so confused in ways that the paper does appear to have adequately addressed. I'll just let it go. paper 01-279r2, with the following changes 26:25 was presumably a typo for 26:35. paper 01-282r2 as is paper 01-283r2, with the following changes I'm working from the r1 and my notes, which may be incomplete, but I think I got it right, or at least close. paper 01-284r1, with the following changes pg 13 edit subsumed in other edits to same sentence. pg 31 Easiest way to keep frame from doing this wrong was just to slightly reorder items in the list so that the "-" wasn't near the end of line. pg 113 The "op" issue looks like a pdf reader font problem to me. Looks different when I use different pdf readers; I don't see any obious problem in the Frame source. The paper suggests that someone (me?) might grep for more NULL() cases. I gave up on doing this as I'm behind schedule and some of the cases might actualy require thought. paper 01-286r2, with the following changes Seems to me like C534 (C532c in the paper) is redundant after the previous constraint (if something has the external, intrinsic, or parameter attribute, then it couldn't be a procedure pointer or named variable). But I entered it as specified. In C532e&f of the paper, "with the PROTECTED attribute that is" -> "that has the PROTECTED attribute and is" because the former sounds like the "that is" modifies "PROTECTED attribute". I think C532e-f would be far more appropriate in the subclause on the PROTECTED attribute, and I find the stated argument to the contrary unconvincing, but I entered it as specified. "" -> " or " since those are the terms we now use; seems like both apply. (I'd forgotten that and wrote a whole para justifying why I'd deleted the "the" even though it sounded worse....before I noticed the more serious problem that there is now no bnf term .) If these words were copied in style from somewere else, that place is probably wrong also, but I didn't go searching - I'm too far behind schedule and it isn't trivially obvious how to grep for it reasonably. Used numbered list instead of bullets. And added commas after the 2 "if" cluaes in the list. paper 01-298r1 as is paper 01-299r2 as is paper 01-313, with the following changes [13:39] presumably meant 13:29. [13:34] no. Causes confusion with table 2.1. Discussed with ISO. [16:22] and "a" -> "an", likely where the "n" was "aimed". [37:31] Hyphenated "lower-case". For better parallelism, added "upper-case" 4 lines above. [44:31],[45:3] I thought "of" slightly better than "in" here. ("in" could imply that we would continue this example in the cited note instead of that an example from/of that note was being continued here.) [47:43] Um...hmm...not sure. Guess I'll go along. [88:7] no. Would start sentence with bnf. paper 01-314r1 as is paper 01-315r2 as is paper 01-318r1 as is paper 01-319 as is paper 01-320r1 as is paper 01-321, with the following changes [13:9] Edit missed a comma and probably a typo omitted an "s". result hard to parse with multiple "or" lists. I just rewrote it as two sentences. paper 01-322, with the following changes [201:14] no Capitalization of "section". no. Wrong fix. We aren't supposed to say "section" at all. Preferrably say nothing. Where needed for clarity, say "subclause". Yes, I see we have it wrong many places, but we should fix it right. This is one ISO does notice. paper 01-323r1 as is paper 01-325r2, with the following changes "array valued" -> "an array". While trying to figure out whether or not to hyphenate "array valued", I noticed that it is an awfully strange term. It really has very little to do with values. It is a strange enough term that we feel it necessary to define in the glossary. I'm likely to propose getting rid of all the existing cases; in any case, let's not add new ones. hyphenate "assumed shape" when used as a modifier. While on the subject, hyphenate 2 other cases of "assumed shape" in c15 (but leave the 2 cases in c12 alone). paper 01-326 as is paper 01-327, with the following changes Also a case at [259:7] paper 01-328r1 as is paper 01-329 as is paper 01-332r1 as is paper 01-331r1, with the following changes On reflection, I don't think that the changes to talk about UNIT=, FMT=, and NML= specifiers are a particularly good idea. If anything, I'd think changes in the opposite direction would be appropriate (i.e. removing all uses of those particular terms). The terms are potentially confusing in that a UNIT= specifier does not necessarily have the characters UNIT=. I suspect that the former wording was intentionally avoiding this confusing usage. I think a better change would be to use the bnf term in these places. The is the critical thing here - not the optional UNIT= characters. We do use the term for this same purpose in other places (including some cases added by this paper). Likewise for the other two of these. Note that it is just the specifiers where the keyword is optional that this is an issue; all these have distinguishing bnf terms. Some of the other specifiers have nothing other than the keyword to identify them, but that's ok for them because their keywords aren't optional. I entered the paper as is, doing nothing about the above comments...but I think this ought to be fixed or someone is going to think that an isn't a UNIT= specifier unless it includes the UNIT= bit. paper 01-333r2, with the following changes Used numbered list instead of bullets. paper 01-335r1, with the following changes "shall apply" -> "applies" in the edit at [77:36] and in the text at [77:29] from which the style was copied. This isn't a requirement in the sense appropriate to "shall". paper 01-336r2, with the following changes Also "of a" -> "of the" on [15:5] (because the newly added initial phrase provides context to make the subsequent reference definite). paper 01-338r1 as is paper 01-339r1 as is paper 01-341r1, with the following changes The paper doesn't explicitly address how to interpret the requirements relating to the length of optional arguments when the arguments are omitted. I fixed this with what I hope is the obvious answer. The paper appears to give inconsistent requirements for the cases where both kind of error conditions occur: the string lengths are too short and retieval also fails. (Yes, I could imagine such a case - if retrieval of the length information was sucessful, but retrieval of the content wasn't). It is a strange enough condition that I don't really care (and I figure most users are just going to test for non-zero status, so it won't matter which anser they get) so I didn't do an unresolved issue on it. If someone else cares more, they might want to fix it. This just made 13.7.43 the only header in c13 (and possibly in the whole document, though I didn't check) that doesn't fit on a line. This isn't catastrophic, but it is minorly annoying. I didn't do anything about it. It did prompt me to think about eliminating the trim_name argument, which is only there for academic reasons anyway - its not like I expect anyone to actually use that argument. I fixed antecedant problems in the wording for the new status argument of get_environment_variable. (There was an "it" that was obviously intended to refer to STATUS, but by placement referred to VALUE). "and" -> "or" in status description. (I doubt we mean it to be assigned both values). Used "otherwise" in LENGTH description instead of writing out the inverse of the conditions stated in the sentence before. paper 01-343 as is paper 01-344 as is