J3/00-101 Date: 14 Jan 2000 To: J3 From: Richard Maine Subject: Edits incorporated in 00-007 This paper describes the changes in J3/00-007 relative to the previous f2k draft, J3/99-007r2. All page/line references are to J3/99-007r2 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-007 are relative to 99-007r2 This includes edits from papers (all 99-) 179, 180r3, 181r1, 182r3, 183r1, 184r1, 185r4, 186r1, 187r1, 188r1, 196r2, 203r2, 205r2, 209, 211r1, 219r1, 220, 222r2, 224, 231r1, 234r2, 236, 237r2, 238, 239r1, 240r1, 241r2, 243, 244r1, 245, 247r3, 248r1, 249r1, 254r2, 258r1, 259r1, 260, 261r1, 262r2, 263r1, 264, 265, 267 268r1, 270r1, 271r1, 272, 273, 274r2 paper 99-179, with the following changes [383:41] another "a" -> "an" [387:35+] Put "Restriction" in quotes in the note. [387:35+] "processors" -> "a processor" [387:39-40] (and the identical edits) "if" -> "with an X such that" It otherwise reads a bit ambiguously and might be interpreted as prohibiting invocation of the procedure at all if there were ANY inappropriate types; what is intended is just a prohibition against invoking it with those types. [388:16-17] Simillar change to the one above. [393:30-32] Simillar change to the one above. [394:44-45] Used the same "with an X such that" phrasing as in the above edits. The "with X present" part is subsumed in this condition, so we don't then need to say it separately. [398:3+] Used the same phrasing as above. IEEE_IS_NAN did not have the phrase specified. It had a requirement on IEEE_SUPPORT_NAN rather than IEEE_SUPPORT_DATATYPE. I made the corresponding edit, keeping the reference to IEEE_SUPPORT_NAN. I assume that the paper was not intended to change that. (I'm not sure why we wouldn't just let this procedure be called anyway, it being "obvious" that the correct answer is false for any value of a datatype that does not support NaN, but I defer to the committee on that. It would be an extension of the TR, not a contradiction with it, to allow calls that the TR did not allow). [389:1] Left the "be". [385:21, etc] I did this stuff as specified, but I note that we can use the mathematical symbol for infinity if preferred. Frame does have it. I didn't make this a J3 note because its fine either way with me. Just to note that it is allowed. paper 99-180r3 as is. paper 99-181r1 as is. paper 99-182r3, part 2 only, with the following changes Also corrected spelling of "compatible" and its variants in c02, twice in c04, twice in c16, and once in annex A. (Its apparently a spelling error the editor is prone to). I think the insertion at 42:35+ would have been more clear with words more like the original, even if moved here, but I did it as specified. I find the reference to EXTENSIBLE and EXTENDS to be less clear than the original because those keywords aren't on the syntax rule right here. Adding the extra phrase as 75:36 made the sentence a little harder to parse, so I simplified it. Changed "pointer with a pointer association status of disassociated" to "disassociated pointer", a much simpler phrase that we do use elsewhere. And deleted "polymorphic" because the statement is trivially true for the nonpolymporphic case. In the last edit, spelled out "-14.6.2.1.3" instead of just "-3". Even though I agree it would read slightly better, I don't see a trivial way to make Frame do the abbbreviated form and still follow auto-renumbering (and it wasn't worth the bother to come up with a nontrivial one). paper 99-183r1, with the following changes [121:15-16] In combining the 2 paras, the "other" now applies more broadly than before, thus removing the restriction against a bound depending on a (presumably different) bound of the *SAME* allocate-object. I doubt this change was intended. I tried to fix it by removing the "other" entirely. If this is not adequate, it will need a different fix. "contains" -> "has" twice. "variable specified" -> "" twice. This seems more specific. Other variables are likely to be specified in such statements, but only one will be an . paper 99-184r1 as is. paper 99-185r4, with the following changes [156:11-31] I italicized the "target" at the end of the added para. I didn't bother to think out which form (if either) is correct, but the other use in the same sentence was italicized and the grammatical form (namely the lack of a "the") implied the italicized bnf term; so it needed some correction - if not italicization, then addition of a "the". paper 99-186r1, with the following changes [275:6-8] I deleted the ", or both,". Yes, I know it was in the original, but that doesn't make it good. The sentence is quite hard enough to follow without this superfluous phrase. If the reader doesn't understand the meaning of the word "or", then he/she is going to be completely lost here anyway. (Heck, I understand "or" and I'm still lost). Corresponding changed "are" to "is". [275:20-21] Kept a "the" from the original. [275:23-42] Changed the first "the" to "a" (unless this is somehow supposed to relate to the same dummy argument talked about in the previous para, but that doesn't look likely). paper 99-187r1, with the following changes The bnf syntax stuff proposed at 32:34+ seems inappropriate for several reasons. First, it doesn't make for much of a definition; it would be better to have a definition that talked about what a deferred type parameter is rather than just defining it in terms of the syntax used to specify one. Second, nothing else in this area talks about syntax. The syntax isn't even introduced until 25 pages later. That forward reference would be ok if it was actually necessary to talk about syntax here, but as is it just makes the statement look more out of place. Note that of 4.5.5 is where the syntax is tied to the property; it seems appropriate there. So I reworded the first sentence of the addition at 32:34+. I think that the defining property of a deferred type parameter is that it can change during execution, so I used this concept. I did avoid naming specific statements. One might want to fine tune the definition to distinguish between deferred and assumed, but I didn't come up with a good idea for how to phrase that and decided it wasn't absolutely required. For the second sentence, I don't understand the change from "objects" to "entities". It might be correct - I didn't think it through enough to be sure. But if so, then surely we should also be talking about entities in the following two paras. I made all 3 consistently "object". If it should be "entity", let me know. But surely it shouldn't be "entity" one place and "object" the other two? I also left the "only" in; without it, the sentence is a lot less informative. We really do want to say that it is allowed *ONLY* those two cases, not just that it is allowed there and might be allowed elsewhere also. Why have two almost identical paragraphs/sentences for the separate cases of allocatables and pointers? It doesn't seem like we should need to make that much distinction here. I combined the sentences into a single list of the places. One can look at the specific statements listed to see which can apply to allocatable vs pointer when one cares. paper 99-188r1, with the following changes The paper claims that the edit for issue 140, plus deletion of a misplaced and now redundant para in c12, adequately covers issue 140. I mostly agree, but issue 140 also pointed out problems with note 7.47 in section 7.5.2. Some other paper does seem to have fixed most of the issues mentioned, but did nothing at all about the problem of being unclear that it is type parameters (as opposed to some other kind of parameters) that are being discussed. I went ahead and fixed this by adding the word "type" twice in note 7.47. I thought this a pretty obvious fix. I do wish that people would read the *WHOLE* of an issue before claiming that it is all resolved. Perhaps this would be easier if I didn't blather so much. :-) I simplified two of the pointer cases into one ("disassociated or undefined association status" == "not associated"). The other wording was ok, but this seemed simpler. paper 99-196r2, with the following changes Added "The" at 172:30+ to avoid beginning sentence with bnf. Deleted the constraint on at 172:34. Since the 172-31 deleted the only use of type-name, this constraint is moot (and thus very confusing). Changed to at 172:37, since there is no longer a here. Doesn't much matter to me which form we use. Indeed, I could see arguments for the shorter one. But we do need to be consistent. Use in bnf for associate-stmt, per 1.6.3. Added commas after 2 "if" clauses in 1st para of 8.1.5.2. I put all the examples in 8.1.5.3 into a single note instead of four just because it seemed convenient at the time and they all fit easily into a reasonable-sized note. Can be separated if desired. I didn't actually read the examples to check that they made sense. Probably they do, but don't assume that I checked. Added the serial (Oxford :-)) comma in 368:30+. paper 99-203r2, with the following changes Section xrefs are in parens only if they are parenthetical. [46:37] The resurected sentence "If is of a type for which default initialization is specified for a component, the default initialization specified by overrides the default initialization specified for that component." strikes me as horrible, (too many components confused with each other). But the resurection is accurate (this thing was an abomination before it died). I'm leaving it as is, at least for now. A few of the other resurected sentences elsewhere in this paper also strike me as equally messy, but I'll not mess with them either (or even keep a list). Too much else to do. The edits for 78:17-18 and 277:41-42 resolve issue 199, although the paper didn't note that. I removed that issue. The edit for 81:18-36 is also resolving issue 195. The edit at 122:28-45 resolved issue 196 and resurects issue 7. [122:28-25] Fixed one more "array" -> "object" (in the last line). The edit at 123:2-5 resolves issue 197. paper 99-205r2, with the following changes [71:19+] "shall not contain more than one" -> "shall consist of a single" I think this a little more clear, since it also may not have less than one (a <-list> never may). Same change in [88:26+] [84:33+] "the variable" -> "a variable" in the first sentence. No specific variable has yet been introduced for the "the" to refer to. "as specified in" -> "as described in" mostly just to avoid using "specified" in two different senses in the same sentence. "contains" -> "has" (or simillar substitutions) several places. because we have a specific technical use of "contains", I try to avoid the possibilities for confusion from also using the word in its more general sense. Yes, the standard already does so quite a bit. And its not actually wrong. But I try to avoid introducing more cases unless its too awkward to word otherwise - all these cases seemed pretty easy. I think you probably mean "does not" instead of "cannot" in the sentence after the constraints on bind-spec-list in 5.1.2.15, but I've never gotten straight how this terminology is being used, (probably because its not used consistently) so I'll leave this case alone....later...paper 99-270r1 fixes this. I rewrote the last sentence in 5.1.2.15. As written, it was not entirely clear whether this was a requirement on the processor to infer the SAVE attribute from BIND (I presume this to be the correct interpretation) or whether this was a requirement on the program to specify the SAVE attribute if BIND was specified. I used words simillar to those used elsewhere about one attribute implying another. I also explicitly said, as we do in simillar cases elsewhere, that it was ok to confirm the implied SAVE attribute by explicit specification. I assume this was intended to be allowed; if my assumption is wrong, then this better be made clearer for the others that will misinterpret it the same way I did. I made the heading of 14.6 plural (Scope of binding labels). Whereas I probably agree that it is better in the singular, all the parallel section headings are plural (except for 14.5, but thats because there is only one assignment symbol), so I made it consistent with them instead of changing the others (though I wouldn't object to changing them all). It is generally considered questionable to make a subsection division when there is only a single subsection in a given section (i.e. 16.2.7.1 when there is no 16.2.7.2), but I let it go. Its not an absolute rule. I added the serial comma in the glossary entry for binding label. I also italicized all the appropriate words in the glossary entry for binding label. I'm darned close to suggesting that we drop this glossary convention. I seem to be the only one who pays any attention to it....and I don't actually like the convention. Added statements:BIND index entry in addition to "BIND statement". paper 99-209, with the following changes I presume that the edit is intended to be on page 84 instead of 85. paper 99-211r1, as is. paper 99-219r1, as is. paper 99-220, with the following changes "may" -> "might" in the edit at [184:31]. "may be permissible" translates to "is permissible to be permissible", which I doubt is what was intended. paper 99-222r2, with the following changes [197:21+] I added "and 10.7.7" because thats the only place where the role of the ROUND= in the io-control-spec-list is mentioned. paper 99-224, with the following changes The edit at 132:37-39 had too many "and's" strung together with no punctuation in between. I changed one of them to "; they". paper 99-226, as is. paper 99-231r1 as is. paper 99-234r2 as is. paper 99-235 as is. paper 99-236 as is. paper 99-237r2, with the following changes "inquire if" -> "inquire whether" In fact, did a global change of "inquire if" -> "inquire whether" in c15. Both forms were used with little apparent pattern. "Inquire if" was used nowhere outside of c15, and the "whether" sounds better to me (not that I can objectively say why). Deleted all 3 references to 9.5.1.10. I agree that it makes sense for there to be an appropriate 9.5.1.10 (that is the substance that remains in unresolved issue 64), but there currently isn't, making it hard to xref. Deleted a "the" in the 2nd and 3rd edits. paper 99-238r1, with the following changes Added two serial commas. [xv:31] Flipped a virtual coin about whether to leave the "is" as is or to also change "ability" to "abilities". The later won marginally. Probably doesn't matter much, as this stuff is very likely to get rewritten anyway in the process of reorganizing the intro, which is badly needed. [xvi:3] "that" -> "which" [xvi:13] Added a "the" [xvi:36] The comma is grammatically "wrong", or at least questionable, but I left it anyway because the sentence is hard to parse without it (and it is acceptable to add otherwise questionable commas in such cases). I didn't go to more work because all the stuff about what's new in f2k will need rewriting anyway for organizational reasons. paper 99-239r1 as is. paper 99-240r1 as is, with the following observation The paper addresses issue 14, but doesn't say to remove issue 14. I'm not sure whether this was just an omission or because there is further work still needed on the issue (and I didn't take the time to figure out which I thought most likely). So I did exactly as the paper said, which leaves issue 14 unchanged. paper 99-241r2, with the following changes Delete "section" twice. ISO style just uses the number alone. (And in cases where we insist that it is ambiguous with just the number, as we did for one place, they want the term "clause"). I changed "occurs" to "occurred" twice. It seemed odd that in step 7 we determine whether an error "has occured", but then three steps later, we talk about whether one "occurs". If it was in the past at step 7, then it still is at step 10. Otherwise, it makes me wonder whether this is talking about the possibility of new errors occuring after step 7 (it isn't, by the way). paper 99-243 as is. paper 99-244r1, with the following changes Added a that. Fixed list punctuation. All these list items should end with commas instead of periods. (Corrected one other case of that in addition the the ones in this paper). And moved the "or". There are 2 insertions at [263:24+]. Doesn't look like the relative order of those 2 was probably important. paper 99-245, with the following changes The replaced text also included the word "abstract". paper 99-247r3, with the following changes Edits aplied relative to 99-007r2 (as there is no r3). "pointer assignment operation" -> "pointer assignment". I don't see that the "operation" is needed, and it just adds potential for confusion. We have a definition for "operation". Its in the glossary and index. This doesn't fit that definition. Delete all the "the"s before and . These aren't necessary in this context. Its certainly not a strict rule. There are exceptions. (For example, I often explicitly add a "the" to avoid starting a sentence with a bnf term). But we don't usually use the article in this kind of context for a bnf term. The descriptive terms are different. I.e. generally "the target", but just "". paper 99-248r1, with the following changes Added two serial commas. Made the last xref to 13.17.1, just like the first. Nothing relevant is in 13.17.2. (Looks like just a typo). paper 99-254r2, with the following changes [75:24-25] "and" -> "or". (The declared type isn't both of these; its one or the other). [75:27] Since we just defined the term "unlimited polymorphic object" two sentences before, lets use the term instead of repeating the same description of the syntax used to declare one. Also rephrase the definition to be consistently in the singular (instead of singular for the unlimitted polymorphic case, but plural for the other two). Also, I thought it a bit confusing to talk about a class of types; too many "classes" here. Yes its a related idea, but alas not identical. So I rephrased that bit; someone might want to check my rephrasing, but I think I kept the intended meaning. [121:6+] Added an "A" to avoid starting a sentence with bnf. [121:9+] Added "values of the" before "kind type parameters". I suspect that is what was meant. (This is along the line of one of the other papers recently passed - I didn't track down which one), [154:26-27] Added "The" to avoid starting a sentence with bnf. [155:16-17] Added another "The" for the same reason. [323:34-35] Downcased the "The" instead of deleting it. paper 99-258r1 as is. paper 99-259r1, with the following changes [7:6] I was uncertain of the correct capitalization style here. The paper has the style I'm most used to for titles. But I see that all of the other ISO references have a different style. I'm not sure whether the paper is wrong, the other references are wrong, or both are right and its just inconsistent. I made the guess and changed the one from the paper to match the others. I could be wrong (not that its of Earth-shattering importance). Use the same "a value equal to that of" phrasing in all 4 cases (motivated more by a bad line break than anything else, but consistency seemed like a good excuse). Hyphenated "4-octet" used as an adjective. paper 99-260, with the following changes Added articles to the start of several definitions. It seemed to me that the previous definition of "prototype" was correct in stateing that a C prototype was analagous to a Fortran interface body, rather than an interface block. An interface block can include multiple interface bodies and procedure statements. So changed "block"->"body". Correct me if I'm wrong. The use of the word "comprised/comprising" in the definitions of "unsigned" and "void" seems a little strange to me, but I'm not actually sure that its wrong, so I left it alone. (A type is comprised of things in addition to values. But the definition of "comprise" I checked didn't actually say that the term implied exclusivity, so perhaps my ear is just hearing it wrong). paper 99-261r1, with the following changes Reformatted one comment to avoid line wrap. Used the same italicization and capitalization convention as the other ISO references appear to. paper 99-262r2, with the following changes "have the SEQUENCE property or with the BIND(C) attribute" doesn't make grammatical sense. Reworded. "can not" -> "cannot" ...later. Changed this to "does not" instead, per the resolution of issue 165 in paper 99-270r1. (Or we'll need to re-open the issue). Deleted the comma in the standard note. paper 99-263r1, with the following changes I was unsure in Table 2.1 how wide to make the new block for IMPORT statements. I at first made it as wide as the one for IMPLICIT statements, interpreting the "add above" part of the instructions to possibly imply this. But I'm not sure of this interpretation. AFter some thought, I realized that it made no current technical difference, since FORMAT and ENTRY statements can never appear in the same scope as IMPORT statements. Thus I nade the IMPORT statement block as wide as the one for USE statements, figuring that the two have similarities and that this would make it easier if we later decide to allow intermixing them (which I'd at least mildly favor). The paper uses the terms "enclosing scoping unit" several times, and "containing scoping unit" once. A grep for "enclos" revealed no other uses in this sense. I didn't grep on contain, knowing it would give more results than I wanted to read. We define the term "host scoping unit" in 2.2, and I think we pretty consistently use that term as far as I know. Yes, I checked that it does apply to interface bodies; they do have a host scoping unit, even though they didn't used to have any host association from it. So I consistently used that term here. The combination "defined...or accessible" seemed confusing to me. Isn't accessible sufficient? Surely any entity defined in a scoping unit is accessible there. Lets check How do we do this for simillar things. Section 14.6.1.3 just talks about entities "from its host" when defining host association. Section 11.3.2 talks about entities "in the module" when defining the USE statement. I don't quite see in either case where it explicitly says that anything accessible in a scoping unit counts as being "in" or "from" it. But it must be at least implicit somewhere. (If it isn't, then we better fix these). At least the examples probably make the intent clear. So I changed these edits to use the same terminology - just "from" or "in" rather than "defined in or accessible in". Thinking further, this wording avoids another nit. You don't just want a name of an entity that is accessibe in the host; you want the name by which it is accessible in the host. In the case of use association with rename, there might be an issue with the paper's wording. [265:24+] I doubt that you want to require all entities in the host scoping unit to be declared prior to the interface body - just those that are imported. Fixed that. ALso singularize the statement. "specification statement" -> "statement". Otherwse we'll go through the same process as we did before to fix up this same kind of thing for USE statements. There are lots of statements that aren't specification statements that need to be covered. (I forget why anyything in the specification-part isn't called a specification statement, but it isn't and I'm sure there was a reason somewhere). For the corresponding condition in USE, the current draft says "nonexecutable statement". There are no executable statements in an interface body, so just "statement" seems like plenty. I pretty much rewrote the insertion at 369:32. In addition to the changes mentioned above, I used the same "has access to" phrasing as the preceding sentence, rather than switching to "accesses". More importantly, there were two cases of being unclear what a phrase was modifying. One might have read it as talking about "IMPORT statements from its containing scoping unit" (instead of those in the interface body). This misreading might seem confirmed if one interpreted "by host association" as being how the IMPORT statements from the host applied to the interface body. paper 99-264, with the following changes "when" -> "where", as mentioned on the floor. paper 99-265 as is. paper 99-267, with the following changes Swapped things around in the definition of "assumed type parameter". It seems better to have the defining first sentence be on what the term means rather than on what syntax is used for it. Then added a simillar sentence about syntax after the definition of "deferred type parameter." Now that this section actually has syntax in it, such a statement seems appropriate. Anyway, it makes sense to express the assumed and deferred cases with parallel wording. ...later...Oh, I see. You probably were trying to make the wording parallel; but it was parallel to what paper 99-187r1 originally said in its definition of "deferred type parameter" instead of how I revised it. And 99-187r1 originally had syntax stuff that I deleted as being out of place because nothing else near here had anything to do with syntax. Now that some actual syntax bnf is here, talking about it makes more sense. So I'm just putting back a re-ordered version of what I deleted. [33:8-19] Issue 134 was already deleted by 99-187r1. At first I wondered why you said to delete it when this paper doesn't address the problems it mentions. But 99-187r1 did address them. paper 99-268r1 as is. paper 99-270r1, with the following changes [404:25-30] Added a serial comma. The last sentence of the para added at 404:25-30 has no verb; I added "define", though "describe" would be another possibility. Also, I recall that ISO doesn't like us calling things "sections", so I changed that to "subclauses" (which I agree sounds less natural, but that's what they use).. The last line of the edits for issue 165 refers to edits for [411:35+] but then doesn't say anything specific. I did nothing. looks like some work is still needed there, but issue 218 looks adequate to flag that lack. [64:15] Changed the sentence to singular. Also, using the phrase "the enumeration type" without antecedant falsely implies that there is only one enumeration type. I changed it to "a corresponding enumeration type." [361:18-20] retained the "in the same program" of the original. Also changed a comma to a semicolon. paper 99-271r1, with the following changes In the 2nd added constraint, added "any" before . There may be multiple ones - I assume this is what you mean. In the 3rd added constraint, omitted "BINDNAME= or NAME=". These are the only kinds of bind-specs that there are. I found the qualifier confusing, making me wonder what the other bind-specs might be - there are none. In the edit for issue 152, "the"->"a" before "". There may be multiple prefix-specs. Only one of them may be a BIND, but that's not what the above "the" would be about. Added "to have" after "allowed" in the new note. Changed "should...have" -> "if...has". We should reserve the word "should" for its sense as a recommendation. Using some words with double meanings is ok (for example, I have no problem with using "set" with meanings of both "a collection" and "assign"). But words like "should" and "shall" are too important to what standards are about. We should use them only with a single meaning. paper 99-272, with the following changes "if" -> "of" as noted on the floor. Retained the "numerical" before "codes" in the edit at 39:37-39; it seems clearer that way. paper 99-273, with the following changes Also added RC to the section heading for 10.7.7 paper 99-274r2, with the following changes I see that, in moving to a constraint, the wording was changed from "may be specified only" to "shall be specified only". Oh dear! I always have trouble getting the fine distinctions between those forms right. I think the "may" is more appropriate here, but its confusing. Lets go with the same form as used in at least one of the other constraints in 5.1, namely "is permitted only". (I'm not sure whether its really better, but at least its locally consistent). We don't need the identical constraint both in 5.1 and in 5.2.12. The first para in 5.2 covers us for 5.2.12. We don't have such duplicate specification for many of the other constraints in 5.1. Hmm. Looks like there are some duplicates, but we should be fixing that rather than adding to the problem. Actually section 5 needs a substantial re-organization, but I'm not up to that - at least not right now and not without help/feedback. Along simillar lines, the first 3 edits for part 3 in the paper are really in the wrong place. The paper doesn't duplicate these, but it does put them only on the attribute statements in 5.2, presumably relying on 5.2.0 to make them apply also to 5.1. We do it the other way around - put the constraints in 5.1, where all 3 of these can be expressed in a single constraint, namely "The ALLOCATABLE, POINTER, and OPTIONAL attributes shall not be specified for a dummy argument of a subprogram or interface body that has a ."