J3/00-162 Date: 3 May 2000 To: J3 From: Richard Maine Subject: Edits incorporated in 00-007R1 This paper describes the changes in J3/00-007R1 relative to the previous f2k draft, J3/00-007. All page/line references are to J3/00-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 00-007r1 are relative to 00-007. This includes edits from papers (all 00-) 104r1, 105r3, 108r1, 109r2, 110, 111r2, 112r3, 113, 114r1, 115, 116, 117, 120r1, 122r2, 127, 128r1, 130, 131, 132r1, 134, 136r1, 137r2, 140r1, 141, 143r2, 144r1, 145, 146r1, 147, 149r1, 150, 151r1, 153, 154 paper 00-104r1, as is. paper 00-105r3, with the following changes The global search and replace of type-selector and "type selector" included the cases inserted by 00-104r1. This seemed correct, so I let it do so. (Good thing I entered 00-104r1 first or I might not have noticed). 153:26-17, and a few other places. I forget what (if anything consistent) we were doing about the use of "type parameters" vs "type parameter values", so I entered the edits as per the paper. Did wonder briefly whether or not it was better to add "values", but time is short, so I did the easy thing, figuring I'd need more checking to justify changing it than to enter it as given. (And perhapos the checking would even convince me that it is ok). 153:30 Changed one case of "the type parameters" -> "those". Nothing really wrong with the original, except that the word "type" appeared so many times in close sucession that it seemed hard to read. (Four words out of a sequence of 11 were "type"). This shortened the sentence by a few words (and one of the cases of "type"). Then did the same substitution on the next edit. 153:32+ I put this edit after the one of 00-104r1 in the same place. 153:32+ Either "the associate name" or "". Not "the " (except at the beginning of a sentence, where I'll sometimes add a spurious "The" as the lesser of two evils to avoid beginning the sentence with bnf). I flipped a proverbial coin and decided on he first form here because thats what the preceding paras had been using. 153:32+ "remaining" -> "other". I suppose either is ok, but "remaining" has a little more flavor of something that starts with a specific set and then subtracts some. I guess the set here is that of all possible attributes. I'm probably being overly silly here in that either word would work. 155:9-12 Same changes as for 153:32+. In fact I just copied that sentence. 155:18+ Added a serial comma. Also ", and" -> "; it" paper 00-108r1, with the following changes Kept the correct list punctuation (comma at end instead of period). Same change at 206:27. That spot doesn't absolutely need it, as it isn't referring to the values defined in ISO_FORTRAN_ENV, but the three sections on ERR=, END=, and EOR= seem better with the same wording for all three cases. "or" instead of "nor" in the 2nd edit. (You don't use "nor" with all negatives; "no" takes "or" instead of "nor"). paper 00-109r2, as is. paper 00-110, as is. paper 00-111r2, with the following changes 257:41 Omitted "with a target" as superfluous. The sentence is long enought anyway and this doesn't add anything. A pointer can't be associated without being associated with a target. The only time we'd need to say "with a target" would be as a referent if we were about to refer to the target. 259:22-23 "and" -> ";". Otherwise its confusing what the "and" refers to at first reading. paper 00-112r3, with the following changes Added a serial comma in 235:23+ and 236:3. Deleted a comma in 11.1.1.2. Is it "argument text program argument", "argument text array program argument", or just "argument text array"? All 3 forme were used. After some debate, I used "argument text program argument." Not sure this is the best choice (the duplication of the word "argument" makes for difficult reading), but it seems like we ought to at least be consistent. Likewise for "argument length program argument" vs "argument length array argument" vs "argument length array". I don't think you want to say that the argument text array contains the text of the command. That phraseology implies that the arguments are defined as part of the command in some sense. The arguments could well be supplied independently of the command. Just describe it as containing the text of the command arguments and the command name. Thats exactly what it is defined to contain. Any possible relationship between the command arguments and a command is irrelevant. Likewise, just talk about the i'th command argument, not the i'th argument "after the command name." The "after" phrase implies things that we don't belong talking about here - namely how a command line gets parsed into arguments. We just want the i'th command argument - let the system worry about which one that is. I don't know what a "significant character string" is. I do know what a "significant length" is. So changes "length of the significant character string" to "significant length of the character string". Yes, I know this was also in the replaced text - but I hadn't proofed that very carefully. I find the present/absent distinction in 11.1.1.3 to be more confusing than helpful. Sounds like you are saying that there would be a character string in the argument text argument if it were absent...or something. Reworded to talk about the significant length of the corresponding command argument or command name, and said that the correspondence was as described for 11.1.1.2. The paper said to pick one or both of the examples. I did (the simpler one). Note that the editor in general requires that J3, rather than the editor, make such choices. (Even though the editor may well have an opinion, he thinks it is a J3 choice). But I think this one was a reply to one of my own suggestions, so I'll accept it. Expanded "Examples:" to "Example of the use of program arguments:" The second example used element 1 of the arrays without checking that there was such an element. There quite easily might not be. This doesn't seem like the kind of thing we should encourage by showing examples of in the standard. I changed it to print out all the available arguments, which seemed simpler than testing. Also, I changed the names in the example to something distinctly different from atgument_text and argument_length to avoid confusing people into thinking that there was any significance to the names used to describe these. (Yes, I know we say there isn't, but still). Besides, the shorter names helped avoid a continuation). I was confused by the capitalization style (apparently keywords in all caps, but only in specification statements - most user names lower case, except for the program name?) So I used my own (everything lower). paper 00-113, as is. paper 00-114r1, as is. paper 00-115, as is. paper 00-116, with the following changes 350:12-13 Moved the "by host association" phrase to right after "accesses" to avoid possible misreadings. paper 00-117, with the following changes Three more cases of "a" -> "an". paper 00-120r1, as is. paper 00-122r2, with the following changes The numbering so carefully specified for the edits on page 353 was still wrong (I think it forgot about the deletion of the former item 3), but Frame did it right anyway. I did make sure to correct the item number cross-references. I put the 2 character cases on page 353 adjacent (and adjusted the item number xref). Simplified the introductory wording for the example added on 386. [386:29-30] "its length" -> "the length of the Fortran entity" to avoid confusion. And replace "expression that is an initialization expression" by just "initialization expression"; the "expression that is an" bit just seems like extra words that don't add anything. paper 00-127, as is. paper 00-128r1, with the following changes Papers 00-128r1 and 127 had different wording (with the same substance) to fix issue 89 on page 65. I merged the fixes, taking the parts of the wording that I liked best from each.k 66:10-11 Added a comma and an "it" to avoid reading "is not a dummy argument" as modifying specification-expr. I also changed a case in the constraint in 5.1.2.4.1. Check to make sure I got it right. I couldn't figure out why the funny wording about "depend on the values of nonconstant expressions." Seems to me that's a lot like just being nonconstant expressions (now changed to not being initialization expressions). Let me know if I missed something subtle (or not so subtle). Its not new to this paper, but while doing the edit at 75:27 (5.1.2.4.4), I also changed "declared" to "determined". Declaration is a concept related to the source code, not to run-time execution. Note that the word "determined" was used for a comparable statement about automatic arrays in 5.1.2.4.1. 244:17-18 Included the "an" in the text to be replaced. paper 00-130, with the following changes 247:14-21 Procedures are not defined by ENTRY statements. Procedures are defined by subprograms. There are already several places in the standard where this is incorrect, but no sense in adding more. See paper 00-127 (the part about issue 162) on this. I changed "defined" to "named" for this case. I think that makes it both correct and sufficient for what needs to be said here. paper 00-131, as is. paper 00-132r1, with the following changes There were two insertions at 78:17+, with order unspecified. It looked to make more sense (as much as any of this does), with the new note before the new para. Deleted the first comma in the note. The phrase "by means outside of Fortran" is not parenthetical; it modifies "change", and critically so. It needs to be closely tied to "change", not separated. The meaning of the sentence would be radically different (and ludicrous) without the phrase. Conversely, added a comma after "while a pointer is associated with a target". Actually this phrase seems moot, as the sentence starts with a condition that the value of the target can change (sort of hard to be satisfied if there is no target). But since the whole section seems moot, I don't know why I should pick out this case to fix. I entered it as specified (except for adding the comma). The rest of my comments here are not really a change; just a note about how meaningless the whole volatile attribute has become. I am unable to distinguish any difference between having the volatile attribute in the standard with this definition versus not having it in the standard at all. (Since not having it in the standard at all wouldn't much bother me, neither does this really - it just seems pointless). As we have it now, if a program uses the volatile attribute, then the interpretation of the entire program is processor dependent. The interpretation of nonstandard programs is also processor dependent. The distinction, if any, escapes me. In both cases, all arithmetic expressions could be interpreted as evaluating to 42, and comments could be interpreted as executable statements that do external file I/O. And if an object becomes defined by a means other then the standard, then the program or processor is nonstandard by section 1.5. In that case, section 5.1.2.3 requires that the code have the volatile attribute. But since the program would still be nonstandard, with or without the volatile attribute, the requirement is moot. So I could probably condense the whole section to "Any program that needs or uses the volatile attribute is nonstandard, but this section is here just to confuse people into thinking otherwise. We made up a bunch of requirements - but follow them or not, its all the same." But I entered the words exactly as passed instead. I didn't even make this a J3 note because as best as I can tell, this was all done consciously and doesn't need a J3 note to point out. Still, I wanted it recorded somewhere other than in the unwritten memory of discussion on the floor...and since nobody ever reads these "edits incorporated" papers, this seems as good a place as any. :-) paper 00-134, with the following changes Note that paper 00-154 supersedes the first sentence of the edit at 257:13+. paper 00-136r1, with the following changes Fixed list syntax. The "or" deleted from 352:45 needs to be added at 352:37. And the comma needs to be left at 353:7. If you want the list in 14.6.2.1.3 to be introduced with "when", then the list elements need to make grammatical sense with "when". All except for (4) are ok. But a noun phrase (when execution) doesn't work. Needs a verb in there somewhere. I changed (4) to "A RETURN or END statement is executed...". paper 00-137r2, with the following changes Used just one article for the whole list at 208:27 and 208:31. I'm not sure why the original had an article per item. Changed both cases on 357:16. Search with Frame verified that no cases of errmsg remain in section 9. paper 00-140r1, with the following changes 244:16 I combined all three "whether it has the * attribute" forms into one list element. Probably would be cleaner to convert some of the other elements to the same form also to make for a shorter, simpler sentence, but I didn't. In the added constraints, "attributes" -> "attribute" (twice) to go with "either". Put hyphens in copyin and copyout. No hyphen in non-predictable. Change "copyout" to "the copy-out" with no quotes. paper 00-141, parts 1 and 2 only, as is. paper 00-143r2, with the following changes 7:3-5 Capitalized "reference" - one of the options Van suggested. 17:37-38 Also replace " and" by ";" in the same sentence. 18:37+ "derived-type specifier" is hyphenated as shown. paper 00-145, as is. paper 00-146r1, as is. paper 00-147, as is. paper 00-149r1, with the following changes. Edit at [50:20+] done at [58:20+]. Presumably a typo. In note added at 58:34+, lets not talk about being the "target of interoperability". We define the term "companion processor" in 2.5.10. Let's use the defined term instead of confusing people with using "target" in a way unrelated to the TARGET attribute. Also, its really "a" Fortran processor, rather than "the" Fortran processor. The requirements mentioned apply to a C processor used as a companion processor of ANY Fortran processor rather than some specific one. "but with names that might be" -> "even if the names are". I corrected the declaration of the ENUM PRIMARY_COLORS in the example to conform to the syntax specified in the bnf. The bnf syntax shows the double colon in an enum-def-stmt to be required. (I suppose perhaps the bnf might be wrong, but I changed the example to agree with the normative bnf, rather than changing the bnf to agree with the example). "more than one" -> "multiple" (and statement->statements) "rather than declaring them" -> "or" paper 00-150, with the following changes. I didn't bother with things like grammatical editing for the unresolved issues, which constitute most of this paper. But there were a small number of edits in addition to the unresolved issues. Issue 6, edit at 19:15+ "composed of" -> "restricted to". Characters aren't composed of a character set. "Universal character name" -> "universal character name". I'm not sure of this one without checking the C standard, which I don't have an up-to-date copy of, but it seems odd to capitalize only the first word, but not the other two. I'd guess none or all (and my first guess was none, which is what I did). paper 00-151r1, with the following changes. [121:19] Looks completely redundant with the first sentence in the para to me, but ok if that's what is wanted. Added a comma. [161:20] The result is awful hard to read. Sounds like the ISO_FORTRAN_ENV unit indicates which exception is signalling. Split the sentence into two clauses. [166:10] The instructions said to compare to [166:27-28], so I did. And it seemed odd that they used different words. Either "allowed" or "permitted" seemed equally good to my ear, and ISO also allows (or permits) either, so I flipped a virtual coin and made the new phrase agree with the old one. [179:17-18] The comment about "implies at least one" makes no sense to me at all, but the consistency seems good anyway. But as long as we are going to copy the words from the OPEN statement, and before we further compound the sin (see below), lets make the words better. Change "Each specifier shall not" to "No specifier shall". And lets put the prohibition against duplication as the first constraint instead of in the middle of constraints about specific specifiers. (This also makes it easier to be parallel later). And change open-stmt to connect-spec-list in the duplication constraint for open to make it parallel to all the other simillar ones. And if the object is consistency, it helps to actually read more than isolated sentences. The same wording appears also in multiple other subsections of section 9. I made the corresponding changes in 9.4.5, 9.6.1, 9.7, and 9.8.1. The 9.8.1 changes are slightly different because of a unit not being mandatory. 186:27, 187:5 Wasn't "yes" supposed to mean I was supposed to do something? This says "yes", but then sounds like it is saying to do nothing. *** In general, I find it a *LOT* easier to deal with edits if they are distinctly labelled as a section of edits, instead of intermixed in with a bunch of questions and answers. This is particularly so when I have to carefully read the questions and answers to figure out whether or not an edit is intended. In this paper seems to vary between "yes" meaning an affirmative answer to a question vs "yes" meaning that there is an edit. The problem, obviously, is that this paper is trying to address two diferent people - the author of 00-103, who wants answers to his questions, and the editor, who wants edits. These need to be better separated or we end up with answers like "Yes, we have no bananas." [185:29] Why do we have an "or" separating two things, one of which we use bnf for and one of which we don't. Also, it seems a bit long-winded to talk about "namelist-group-object-list items". That would be just the namelist-group-objects; the "-list" and the "items" essentially cancel each other out. In 5.4, we use the non-bnf term "namelist group object"; that would seem to go well here. paper 00-153, as is. paper 00-154, with the following changes. [69:41-44] "can" -> "may". Its pretty clearly a matter of permission. It is perfectly *possible* to write p=>q where q has a wrong type; the standard just says that you are not *permitted* to. This paper made substantial improvement in 5.1.1.8, but there was still one big omission in my opinion. The definitions of the various terms aren't really definitions. For example, we never say what the term "dynamic type" means; we just say what the dynamic type is in various (hopefully all) conditions. Likewise, we don't say what the term polymorphic means; we just say that things declared with the CLASS keyword are polymorphic, whatever that means. This kind of flaw is by no means unique to this section; indeed its somewhat endemic to the document. But this is the section I'm looking at right now. Besides, these terms are pretty novel to Fortran so we should do a good job of defining them instead of just assuming that people will know. There are actually reasonable definitions for several of the terms in Annex A, so its not like the terms don't have definitions or that we can't write decent ones. I've added a new para at the start of 5.1.1.8, with several of the most important definitions using wording more like that in Annex A. I correspondingly moved the bold-facing to these definitions instead of on the nondefinitions in the subsequent paragraphs. It seemed easier to just do this than to write up another J3 note about it. In the process, fixed up some of the glossary entries as follows. Fixed "assumes" wording in glossary entry for "polymorphic". Removed "polymorphic" from the glossary definition of "dynamic type." The definition of the term "dynamic type" applies to both polymorphic and nonpolymorphic entities. It needed only to delete the word that restricted the definition to polymorphic entities only. The fact that the dynamic type is trivial for nonpolymorphic entities doesn't change its definition. I left the second sentence, which points out the triviality of the nonpolymorphic case, alone. paper 00-144r1, with the following changes. 4:16 No. My ear says to use "than" here. For support, reference Miriam-Webster Online dictionary "usage: Numerous commentators have condemned different than in spite of its use since the 17th century by many of the best-known names in English literature. It is nevertheless standard and is even recommended in many handbooks when followed by a clause." Random House Unabridged, 2nd edition "Usage. Although it is frequently claimed that DIFFERENT should be followed only by FROM, not by THAN, in actual usage both words occur and have for at least 300 years. FROM is more common today in introducing a phrase, but THAN is also used.....THAN is used to introduce a clause....In British English TO frequently follows DIFFERENT..." Alas, I don't have a copy of the OED. Note that the context here is a clause, although that might not be trivially obvious because the verb of the clause ("produce") is assumed. The expanded form of is "f77 processors may produce a different output form than f90 processors produce." I bet most people's ears will agree that "from" is wrong in the expanded form; the same conclusion should apply to the form with the implied verb. I thought this one was stricken on the floor, but its possible that I missed it at the time. 20:8 Also converted the result into a single serial list of 3 items, rather than a list of two items, one of which was in turn a list of two items. 42:23-24 I liked it slightly better where it was (after the bnf for statement was complete instead of in the middle), but not strongly enough to argue about it, so I did it as instructed. In general, I think its easier to read the bnf if the constraints are at the end instead of interspersed in the middle of it, but there are some cases where that would not work without rewriting the constraints, because they become ambiguous when moved. This section is probably one of the worst in that regard. 44:23+ "the" -> "a". There might not be one. 46:23, 58:37 Yes, those were "Frameos". Things like that are where Frame lost track of an xref, which happens sometimes. I don't have any magic way of reconstructing what the correct xref was other than searching through old versions or just guessing what makes sense. I think I got reasonable ones here. They are certainly close, though its possible that one of the other subsections of 7.5 might have been intended. 49:34 Did what the edit meant instead of what it said (i.e. I didn't end up with "within the within the..."). 55:28 Last "the"->"a" (very marginally, because the preceding sentence does talk about values in the plural.) 74:27-28 Also deleted the "the" to make it yet more parallel. (Yes, I know that Euclid would be horrified to find "parallel" used in a comparative rather than absolute sense). 77:44-45 Overlaps an edit by some other paper (I forget which one). That edit did delete the "provided by some processors" bit objected to here. But it left in the comment about similarity. I did the version specified by the other paper rather than this version. Partly because I had already done that before getting here, and partly because I find the comment about similarity useful. J3 may, of course, differ, but I had to choose one of the two versions passed. Also did a lot of the stuff in section 2 of the paper, even though it was nor formally voted on. Took quite a while, I might add, because I did have questions about several of them, including some that I think introduced technical errors. If you want me to treat these things as typos to be fixed almost without thought and without J3 review, then a better job needs to be done of separating the things that really don't need thought or review. I wasn't too pleased at having to do this much work on a section alleged to be "typos". If I'd known before starting that it would take me this much time, I wouldn't have done it. I did have minor doubts about the substitutions for .TRUE. and .FALSE., but I already conceded that one for the earlier sections, so might as well at least be consistent. Did them as specified. Things I did not do in section 2 are: [114:8] I'm not convinced that the issue is unrelated. I think it may be restricting what the first sentence applies to. I think the point is that // is an intrinsic operator...period, but that it only defines an intrinsic operation for the case where the kinds are the same. At least that's what I think its saying. Anyway, I have enough uncertainty to consider it more than typographical, so let J3 look at it. [118:13] The original isn't great, but I'm not convinced the change is an improvement. Short on time to rework, so deferred. [137:1] Instead, deleted the incorrect blank (typo?) in the middle of the word, after which Frame moved the whole word to the first line. [161:7] That is a strange mode of expression isn't it? Almost sounds like a British usage, though I'm not sure of that. I note the exact same wording goes back unchanged to (at least) f77. But that doesn't make it good, I agree. I don't like the "when" either. Almost makes it sound like the specified things will happen whenever the value of the variable changes or some such. So I used the longer, but (I hope) perfectly clear phrase "depending on whether". [168:11] Agree. For that matter, "record specifier" was't even the right informal name anyway; it was "record number specifier." Changed as suggested. [176:40] That note is now in 10.7.7. Found and fixed it there. [183:36] I'll let J3 look at this one. Not 100% sure what is being asked. I think you are asking to split the note into two, though at first I read it as saying to make it normative (which I'd think wrong). But splitting the note does make it a little less coherent. Possibly moving the whole note would be better. All in all, I think this not in the same class as typos, and I don't feel I have the time to work it right now (particularly as this part of the paper wasn't actually passed). [198:1-2] They seem ok to me. I guess I don't see "is prohibited" listed in the explicit list of forms for prohibition, but "is not allowed/permitted/acceptable/permissable" are listed in ISO directives 3, and it uses the term "prihibition" in describing these. I don't see anything wrong with "is prohibited" and it seems shorter than "is not permitted". If this isn't what you were complaining about, then I don't understand the question. [198:8] Done after third "record" instead of second. (This is bound to be where you meant. It doesn't make any sense after the second, but is needed after the third). [204:38] Disagree. See rather long-winded citations above. This one also has an implied verb - "behave". I'm not actually sure what you are talking about by saying that "than" implies ordering. I don't know of such an implication. ("Then" certainly implies ordering, but that's a different word). [205:13] Neither "when" nor "if" seem very good to be. Deferred to J3. [213:21] I believe this proposed change to be technically incorrect. If you think otherwise, you need to convince J3, not me. And you also ought to submit an interp. Note that the f90 standard has this same example in normative text. [216:28] I don't see a "k" on 216:28. I see two on 216:29, and as far as I can see, it would be incorrect to change either one to -k. Whatever this question was, you better take it up with J3. My work on this paper is the only thing now holding up the 007, which is distinctly late, so I'm not inclinded to think any more about it. [219:20] I don't accept typo/grammar corrections to J3 notes. Nor do I track section number changes in them. It's too much work, and I don't want to allow a precedent. I'm sure many of the section numbers in them have become wrong. So even though you are probably right about this, I'm going to be obstinate and leave it alone. The best fix is to remove the J3 note one way or another (by fixing the issue or deciding that it doesn't need fixing). [223:4] ditto. [254:26] Makes the sentence harder to parse. I'm not sure its needed anyway. Deferred to J3. [254:36] Seems like a useful reference to have somewhere around here. Perhaps was supposed to go with the previous edit, which provided a substitute. Deferred to J3. [258:22], [260:20] No. The "then" is there intentionally in order to help parsing of the sentence. The word "then" can often help parsing of sentences by making it clear where a condition ends. In simple sentences, a comma does the trick, but in some cases a comma isn't enough. Particularly in constucts like "If X, Y and Z", which is ambiguous. It could mean "If X then Y and Z" or "If X, Y, and Z then". If you don't like that, you'll find plenty of other cases to expunge from the document. Admitedly, a better fix might be to make the sentence structure less complicated. But just deleting the "then" makes things worse in my opinion. P.S. I would think a Fortran user would be pretty comfortable with "then" following "if"; it sure beats using an open curly brace. :-) [261:38] I'm dubious of whether scoping units do anything active like invoking something. I thought a scoping unit was just a bunch of text. Of course, the same is probably true of a subprogram. I assume you were just trying to fix the problem that it might be a main program hat did the invocation...or maybe a module...hmmm. I dunno. Perhaps you are right, but I think I'll let J3 figure it out. [266:23,40] In J3 note. See above. [273:20] You are probably right, but I don't know what terminology the C standard uses (hmm, I need to find a more recent draft than the one I have, which I concluded at the last meeting was badly enough out of date to be of negative value - I kept drawing incorrect conclusions from it) and I'm in a hurry. Deferred to J3.