J3/02-276 Date: 23 Sep 2002 To: J3 From: Richard Maine Subject: Editor's comments on edits from meeting 162 This paper has the editor's comments on edits passed at meeting 162. Nothing was done about any of these comments; the documentation of edits made is in a separate paper. The comments range from editorial trivia and style preferences up to matters that I believe reflect substantiative technical errors. paper 02-217 Note my first comment about paper 02-241r4. paper 02-219r2 I don't understand the rationale behind the dtio-related changes. Whether this is a shortcoming in the rationale or in my understanding is unclear. I don't see that PASS is even meaningful for dtio since PASS affects only how the invocation is written, but the invocation of a dtio procedure is not written explicitly in Fortran at all. I'm having trouble seeing how PASS vs NOPASS for dtio would actually make any difference at all in how any code would be written or interpreted. This same question applies to assignment. paper 02-220r1 Seems odd to make this fix here, but then not make comparable fixes in the immediately following para. Indeed, grep reveals that there are no occurences of the words "starting" and "ending" anywhere in section 6 other than these two paras. A quick read of these paras reveals that every usage of the terms is actually referring to the values. Seems like a better fix would have been to just include the word "value" in the definitions of "starting point" and "ending point". Though as noted elsewhere, we confuse syntax terms and values so much as to be largely hopless to consistently fix anyway (though not as often as we confuse entities and their names). paper 02-221r2 [397:2,5,8] I'm dubious of these edits. If a component is itself of derived type, I'd say that "its" derived type definition could be misinterpreted as the one that defines the derived type of the component. Of course, that would be ludicrous as a scope, so the odds of anyone getting it wrong are about the same as the odds of anyone getting the original wrong. 397:23 It isn't new, but I still have trouble parsing this sentence (and the similar one in the preceding para). I keep parsing "an argument keyword of the scoping unit" as though the "of" phrase modified "keyword". (Instead it is intended to modify "scope" from earlier in the sentence). 398:11-12 I find the resulting wording confusing. We have both "within a FORALL construct" and "a containing FORALL construct", which makes it sound like we are talking about some FORALL that contains the one that the "within" refers to. We'd probably be better to change the "a containing" to "any containing" and then omit the "within" phrase as redundant (if we aren't within one then there is no containing one). 400:13,16 I can't tell whether these edits make sense or not because I can't parse the sentences they are in (as I suspect I mentioned when these sentences were last abused). Since the sentences talk about multiple "accessed vias" (both host and use association, for example), I'm suspicious that these edits still don't always tell us which scoping unit is meant. If I could read the sentences at all, maybe I'd know. paper 02-223r1 I'd have said "the function" instead of "a function" in the second edit. Everything else in the area is using "the" and the "a" seems out of place as though it were changing the subject. I'd also have said "that of" instead of repeating "the value of", though that's pretty trivial. It would follow the style of the "those of" in the previous sentence. paper 02-224r2 [82:0+] Darned if I can figure out what is misleading about the note, but I agree that the note didn't add anything useful anyway. paper 02-230r3 [382:17-25] I don't know why the result characteristics para was omitted from the revised text. I almost wonder whether this was accidental. Seems to me like the old result charactersitics para was appropriate unchanged. Nothing now says what the old para said. I find the whole result section to be written with inadequate preciseness. The first sentence is pretty much incomprehensible. What is this PX thing? How does it determine a result anyway? Not until reading the subsequent paras can one even guess what the first one is trying to say. It never does really say it. There is an awful lot of vague hand-waving here without actually defining things. I'm not convinced this is any better than just saying "you know what this function should do". As it is, we are just asking the reader to guess what we are trying to say. If there is an actual term for the C "base" address, we should use the term (perhaps just address?). If "base address" happens to be the corect term, then we shouldn't quote the "base". The quotes imply that we don't mean the term literally. [383:14-17] The result description here is less comprehensible than that of C_LOC. IN addition to problems simillar to those of C_LOC, it has expositional problems in confusing requirements with conditions and the like. For example, we have a statement that "The association status of PX has not chamged". What does that mean? I think it is still part of the "as if" condition, but it sure doesn't say that - it just comes out and states it as a fact. Since PX is a fiction in the first place, I don't know how one can state such facts about it. Then we switch into stating what is apparently a requirement (that's what "shall" means) on the target of PX. Is this actually intended to be a requirement? If so, that means it is illegal to use C_F_POINTER in such circumstances. Or is it intended that the call be legal but give an undefined result (much like a pointer assignment to an undefined pointer would)? If this is a requirement on C_PTR, why isn't it stated in the para about C_PTR? There must be a bunch of "if"s or other conditionals missing in the two cases. Such conditionals are not implied by just writing case(something). Headings are just organizational help; they don't get you out of writing the English. For example, the requirement that "FPTR shall be scalar" is clearly nonsense, since a few paras above we talk about its shape. This probably means that FPTR shall be scalar under some condition, but it doesn't say that. This needs complete rewriting, which I'm afraid its not going to get from me. I am surprised that we have no requirements at all on C_PTR except that it be a scalar of type C_PTR. Even if I assume that the now-dangling cases are rewritten to something that have "if"s in them somewhere, nothing anywhere says that CPTR has to fit in either case. We just don't say what happens if it doesn't fit. [471:22+] I didn't even read the code in the samples. I just inserted it with a few cut and paste operations. Assume it was ok. The comma in the first sentence is inappropriate as it stands; I'd have written it as ",which are" or perhaps better (since the C processor might support them) ", which might not be". One or two of the code sample didn't actually have a lead-in. For example, one just says "This may be done using C_LOC..." and then just shows some code, without having anything like "as follows" as a connector. I don't think a definition in a comment in sample code is sufficient to support using an acronym like URNG in the text, as is done in one place. paper 02-238r2 [81:14-17] I wouldn't have used "also" here because I find it unclear what it is in addition to. I'd have just given the complete list, including a instead of implying it with "also". Of more consequence, I don't at all understand the bit about "an interface body that is not in an interface block". I don't see that we allow any such interface bodies. Seems to me that this ought to be an interface body that is not in an abstract interface block. The omission of "abstract" might also be a typo, but that goes beyond what I think I can justify on my own. [253:25] I thought we had some material that depended on making the distinction that a procedure pointer was not classified as a procedure. Alas, I forget where it was. Perhaps it is gone by now. Perhaps it is fixed by this paper. It was a subtle basis for distinction anyway and would probably be better expressed explicitly. I just wish I were sure that it is gone and that this change doesn't break it...wherever it may be. Guess we can fix it if still needed. paper 02-240r1 There is substantial duplication between sections 2.4.6 and 5.1.2.11. I'm not sure what criteria were used to decide what is duplicated and what is not. I'm suspicious that nobody noticed; there are no xrefs in either section to the other. Particularly jarring to me was... The first sentence of the new para in 5.1.2.11 defines the pointer attribute, which seems appropriate, considering that's what the section is about. But then the next 2 sentences talk about pointers, failing to mention the relationship of such a thing to the pointer attribute. You have to go back to 2.4.6 to see that relationship. That might be reasonable, as the things in section 2 tend to be fundamental enough that they get used all over without xrefs (otherwise, the number of xrefs would be unreasonable). But as long as you have to check 2.4.6 to understand the terminology of the second sentence, you'll find the whole sentence duplicated, word for word. [254:8+] I think you mean "local variable" instead of "local entity" at the end of this edit. A dummy argument is a local entity, so saying "dummy argument or local entity" doesn't make much sense. See the definition in 16.0 (and in the glossary). I once proposed defining the term "local entity" in a way similar to the way that "local variable" is defined in 2.4.3.1.1 (then using some other term for what we now call a "local entity"). But I didn't get my wish on that. [262:39-40] Although it seems reasonable to say essentially this up front, I don't like the way that this now refers to the bnf term before its definition. I'd have used English instead (perhaps "a list of procedure entities") like we do in many other similar statements. paper 02-241r4 The edit at 16:32 seems inconsistent with paper 02-217, which removed similar wording from 6.1.2 because it was vague and confusing. I find it even more vague and confusing here, where there is less context. Note that 12.4.1.6(5) uses the term "subobject selector", which is now undefined after the edit at 19:4. But I did it as specified. Also, the "and" should probably now be an "or" (likewise in the glossary). While doing the 19:21-22 edit, I noticed that "may be" appears to be used incorrectly (twice) in that para of the existing text; this is supposed to be a definition (as evidenced by the use of the tdef macro, which bolds and ads an index entry), not permission for anything. While doing the 20:12 edit, I noticed what appears to be an error in the existing text. I suspect that "as an actual argument" would be more appropriate than "in an actual argument list". If the expression x+y appears as an actual argument, then it seems to me that it constitutes a reference to x and y, even though they are "in" the actual argument list. I think this sentence is about cases where the designator in question is the actual argument. I also found myself at loss to figure out what the exception is about, but I'll assume this is just my failing. paper 02-242r2 [41:7] This doesn't look at all like a definition to me. This uses the term but doesn't do anything to define it. The only places that I can now find anything even vaguely close to a definition of "component" are in 6.1.2 - defines "structure component". First sentence of note 4.43 - but that's a pretty obscure place and isn't normative. 2.4.3.1 - defines it parenthetically. glossary - not normative. [41:19+] I'm not sure why we have an isolated sentence about accessibility of type-bound procs here. We don't talk about accessibility of anything else in this area. Also, the "when" is inappropriate and possibly wrong. Finally, this sentence appears to contradict what is said in 4.5.1.8. [47:20] I find the result hard to parse. In particular, it is ambiguous what the ", and" connects to. I could read it as "a subcomponent is default-initialized...and the subcomponent is not a subobject...". The strange comma in a 2-item list contributes to this misreading (but removing the comma makes for other confusions). [47:20-22] Argh. Perhaps unnecessary for some, but it was my only hope of understanding what the previous sentence was trying to say. Oh well. [56:6] This appears to me to be an unintentional technical change. Hope I'm wrong. A nongeneric binding may be either a specific binding or a final binding. I think this change just eliminated overrides of final bindings. [58:37-39] I find "for which... or that has..." to be a bit awkward, contributing to confusion about what the "or" goes with, but I suppose it's not wrong. [61:11-] I have no idea how this sentence constitutes a definition of the term "finalized". Bold is supposed to indicate definition, not just first use (though the two are often the same). [61:33,35,38] I disagree that these qualifications are unnecessary. Without these qualifications the section is internally contradictory. These sentences now say that the entity in question is finalized without qualification. The new first sentence in the section doesn't qualify these sentences; it just contradicts them. John's original, which said "Finalization of a nonfinalizable entity has no effect" would say what is evidently intended, but the current version doesn't. [74:33-34] I believe the edit done here (if I interpreted it correctly) to be the inappropriate edit, but I did it as I think was directed anyway. To my knowledge, the bnf is used only in an obsolecent syntax (the one in the line above). It is therefore appropriate to put its definition in obs font. I do think there was a typography error on these lines in that they were only partially in obs font, but I think the correct form is to put the whole lines in obs font rather than to put the whole lines in normal font. Perhaps that fix was intended, but I can't deduce that from the comment as phrased. [116:13] Not new to this paper, but some of the "an"s in this area should be "any"s. The current wording says that this happens to exactly one argument. If there is more than one argument meeting the conditions, then it is unspecified which one this happens to. If no arguments meet the condition, then apparently the code is illegal. I'm sure this is not the intent. paper 02-244r2 261:7 I don't see the point of including abstract interfaces here (or at the cited 81:13-14). I think this might be a remnant of a prior iteration of abstract interfaces. The paper does say "Or don't have 'an abstract interface' in either place", which seems to imply it is my choice which way to do it, but I don't understand why the choice was left to me. This isn't an editorial matter, as it changes the definition of what code is legal. I suspect that the choice was intended to be J3's, but that it accidentally was left open. I personally suspect that the choice of omitting 'an abstract interface' from both places would be better. 266:15-18 I think this sentence was supposed to cover a different case than the preceding sentence. The preceeding sentence was for type-bound procedures; I think this one was supposed to be for procedure pointer components. So deleting this may loose something. However, I agree that the sentence is so awkwardly constructed that its point probably was all but undecipherable anyway unless one previously guessed what it must have been trying to say (and it still takes slow and careful reading to verify that, yes, it could be interpreted to say what was guessed). paper 02-245r2 [88] Since here is required to be the name of a variable, I wonder why we don't use . Is this a remnant of a time when someone thought that other things were allowed here, or is there an actual reason for this bnf terminology? paper 02-247r1 [46:3-4] I think that deletion of the last sentence of the para leaves a hole in that we don't say what the kind is if it isn't specified. Even though we now do require the INTEGER specification, we don't require the kind to be explicitly specified (and I suspect that explicit specification of it will be relatively rare). The words in 5.1.1.1 don't cover us because those are about the INTEGER type specifier and this isn't an integer type specifier according to the bnf - it just happens to look identical to one. Perhaps the bnf should say that this is an integer type specifier, but it doesn't. paper 02-249r1 I also see similar cases in 9.10.4, but I did nothing about them. (Might be more elsewhere; I didn't search). paper 02-250r1 [257:18-19] Seems to me that another edit is needed here. As is now, an interface block with "ABSTRACT INTERFACE" is both an abstract interface block and a specific interface block (since it has no generic spec). [257:23] I'd have preferred "explicit or abstract interface" instead of "explicit interface or abstract interface", but that's minor. [257:30-31] I'm dubious that "used in any way" is sufficiently precise for normative text. The reader of the standard won't have Malcolm's explanation of the meaning. I could imagine "used" being incorrectly interpreted as "referenced". The "in any way" is presumably intended to fix this, but I see it as just extra words with no extra content. Is the procedure "used" if it is goven the public attribute? I bet the intent is that it not be, but without Malcom's explanation I have no clue as to the answer to this. Even with the explanation, I'm not entirely sure because I don't know enough about implementation to know whether this might cause some implementation sto generate a linkage. Should we allow "END ABSTRACT INTERFACE"? I'm not sure of the answer. Also not sure whether the question was thought of. paper 02-252r2 [397:1-] The use of "may" here is inappropriate; no permission is involved. I didn't try to actually read the new section; I just pasted it in and applied the formatting markup. A phrasing something like "The itemized rules..." in the first sentence of the new section might help people make the connection between the rules and the numbers used in the annex and the. Without the word "itemized", it is less clear to me. Entered as is. paper 02-253r2 [61:8] I think the comma grammatically incorrect. I see the problem it is trying to fix, but adding an otherwise inappropriate comma is a last resort for such things. This one would have been pretty easy to fix without resorting to such. paper 02-254r1 [66:5-7] The wording seems unnecessarily roundabout compared to what we use for similar restrictions elsewhere, but it is neither new nor wrong. paper 02-255r1 [191:14-18] I'd find this to read more smoothly with "any part of which" instead of "of which any part". paper 02-258r1 I'd have deleted what is now the first sentence in the second para of PENDING= section. The sentence is purely about ID= and is now duplicated word for word in the ID= section. By the way, I asked about how to handle this alphabetization quandry then this section was alphabeticized. Oh well, J3 is free to change its mind; I've done so before. paper 02-259r1 [163:22] I don't understand the point of this edit. (How can a selector have those attributes without being a variable?) [287:10] I think this edit makes the sentence both confusing and grammatically questionable. Confusing because the reader might think that "unallocated" modifies "pointer". Grammatically questionable because it links nonparallel forms of speech with an "or". ("Unallocated" is an adjective; the phrase after the "or" is a noun phrase). These seem to me like more serious flaws than the abuse of "allocatable" as a noun. Note that the same use of the phrase "unallocated allocatable" appears 11 times (by my count), and I am not counting places where it is used as a modifier. Why change it only this once? (Though perhaps I shouldn't ask, or all 11 might get changed to be confusing). [196:25] I believe this to be technically incorrect. Statements may have specifiers; operations do not. See, for example the usage of "identifier" in the penultimate para of 9.6.1, and in 9.9.1.12, which would be pretty incomprehensible if "identifier" were similarly replaced by "ID= specifier". The second sentence of 9.5.1.8 specifically says we refer to this as the identifier, which this edit then belies. [231:29,232:1] I find the replacements harder to read than the originals. [232:26] I believe this edit to be technically incorrect. The r is not a rounded value of anything. It is a number relating to rounding, and thus might plausibly be called a rounding value, but it is not a rounded value. It is, by definition, either 0, 1, .5, or -.5, depending solely on the I/O rounding mode and not on any numeric value. [233:1] The list in this sentence is nonparallel, and I think technically incorrect as a result. Three of the four items fit appropriately. However the condition on w-n being positive doesn't belong in the same sentence at all. It isn't a definition of anything used in the table, and thus doesn't belong introduced by "where". It is just plain a requirement on the value of w. Indeed, as now phrased, one could argue that it leaves a technical hole in the standard. With the "where", it is no longer a requirement on the value of w. Instead, it just defines conditions where the table applies. Other conditions aren't now disallowed - they are just not defined by this table. Also I note that the resulting sentence is a little hard to parse because it has a 2-item "and" list nested as one element of an outer "and" list. [239:2] Although I agree the old sentence was hard to parse, the revision leaves it unclear (to me anyway) whether or not the "if" condition applies to the second clause. (It had better apply). [257:22] While entering this, I noticed that the antecedent of the following "its" is unclear (could be "scoping unit" or "interface body"). I'll just assume all the "only" fixes are correct; I can manage to misread several of them, but then I often have trouble with correct placement of "only" so I'm probably not a good judge. Um...except for the one on [134:3]. I believe it constitutes a *MAJOR* unintentional techical change. As reordered, this now *PROHBITS* the processor from evaluating more than is necessary. The former wording left the option to the processor. Seeing this case of what I am fairly sure is an error in the placement of "only" makes me less confident that the other similar changes are correct. Umm...I also think the first two "only" changes on page 274 are substantial technical errors. They changed this from talking about being "only specfic" to being specific "only in a scoping unit" (and nowhere else). (another pair of "only" changes wasn't done because they directly contradicted each other on where to put it). This material on "only" can't have gotten a real review. Perhaps J3 assumed that moving words like "only" around can't change meaning, so it doesn't merit careful review. I assure you that it is possible to majorly change the meaning of a sentence by moving an "only" around. The original paper 02-253 made a similar point, but then assumed that the corrections were obvious. I had expressed concern in pre-meeting email that such things were not always obvious. My concerns appear to have been well-founded. [275:11] This "only" change makes yet a different major technical error in deleting the "only" entirely. It is very diferent for something to be established to be specific and for something to be established to be only specific. If you miss that distinction, much of 12.4.4 becomes inconsistent and incomprehensible. I've always found the section very hard to read myself, but this would chnage it from hard to impossible. Might I suggest that it is a bad idea for people to try to make grammatical corrections to material that they don't understand? I don't see how anyone who understood the material could possibly have proposed this change....and I also don't see how anyone who understood the material and actually reviewed the edits could approve this one. See my pre-meeting rant on the general subject of papers getting approved without getting adequate review. [441:9] I'm suspicious that the "only" placement here is incorrect and also that there is a confusion of "can" and "may". It is certainly possible (as in "can") to put something inappropriate in a deallocate statement, but one is not allowed (as in "may") to do so. paper 02-263r1 [13:7] I find the "also" in "may also be used" to be confusing. Actually I found it confusing before because the referent for the "also" had nothing to do with the preceeding sentence. Now that the former referent ("may be used") is deleted, I find the confusion worse. Did nothing about this. I also find it strange to list the 3 kinds of interface blocks and then say something about two of them. It leaves one wondering what happened to the third. [43:16+] I think you mean a bound in (rather than for) an . I don't know what a bound for one would be. Also, the sentence can be parsed to be referring to a bound for a , which I doubt was intended. [251:1-2,4-5] I'm not entirely convinced that these sentences still cover the issues of the interps that the originals came from. This may be because I'm not sure exactly what does or does not constitute being "declared in the scoping unit of a module". Note also that, according to one of the other papers passed at the same meeting, "explicitly" is redundant; there is no way to implicitly get the EXTERNAL attribute. paper 02-264 [141:18] This sentence now has a 4-element list of the form "w, and x, y, and z", which isn't how such lists are supposed to be punctuated. The fact that 3 of the elements of the list are itemized doesn't actually change that. I'd have put the first element as another itemized item instead of separating it out like it is. [164:11+] Apparently this now requires the => when the selector is a named constant (since that's not a variable). Strange requirement, but then selecting on a constant would be a strange thing to do (but a legal one as far as I can tell). paper 02-269r1 This paper made me wonder about the apparent inconsistency between defined assignment and user-defined derived-type input. Aren't the issues essentially identical for both? Shouldn't the standard therefore treat them identically? The standard says that defined assignment can use either intent(out) or intent(inout), at the user's choice; I'd propose we say the same thing here. Defined assignment was standardized in f90, so we wouldn't want to change that without a lot better reason than I see. Note that the distinction between intent(out) and intent(inout) has more consequences than just definition status. Consider derived types that have final procedures. If I understand correctly, a final procedure would be executed during intrinsic input of a derived type. If I've got that straight (and I might not - I'm still confused on several things about final procedures), it seems odd to not even allow a final procedure in comparable cases of user-defined derived-type input. paper 02-270 [395:17] I don't think this edit makes any sense. If it makes sense, then I'm more confused that usual. I presume that the cited material at [57:3] is referring to the type-bound specifics in the type-bound generics in question, so they are still specifics. The new wording implies that they aren't. Probably the words at [57:3] should be fixed instead. [400:1] It must be me. I was having a horrible time figuring out what this sentence was saying either before or after the change. I almost gave up before I figured out what sense the word "contains" was being used in. I think it would be clearer as something like "is the host of". Since a scoping unit can *BE* a subprogram or derived-type definition, I was thinking that was the sense of "contains". Took me a while to realize that this meant "contains" as in "is the host of" instead of "contains" as in "is".