From owner-sc22wg5@dkuug.dk Wed Apr 30 23:02:22 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h3UL2MgM070756 for sc22wg5-domo; Wed, 30 Apr 2003 23:02:22 +0200 (CEST) (envelope-from owner-sc22wg5@dkuug.dk) X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f Received: from mailhub.dfrc.nasa.gov (mailhub.dfrc.nasa.gov [130.134.81.12]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h3UL0tIo070745 for ; Wed, 30 Apr 2003 23:02:16 +0200 (CEST) (envelope-from maine@altair.dfrc.nasa.gov) Received: from mail.dfrc.nasa.gov by mailhub.dfrc.nasa.gov with ESMTP for sc22wg5@dkuug.dk; Wed, 30 Apr 2003 13:58:35 -0700 Received: from altair.dfrc.nasa.gov ([130.134.20.211]) by mail.dfrc.nasa.gov (Post.Office MTA v3.5.3 release 223 ID# 0-71686U2500L200S0V35) with ESMTP id gov for ; Wed, 30 Apr 2003 14:00:44 -0700 Received: from altair.dfrc.nasa.gov (localhost.localdomain [127.0.0.1]) by altair.dfrc.nasa.gov (8.12.8/8.12.5) with ESMTP id h3UL0lEc032692 for ; Wed, 30 Apr 2003 14:00:47 -0700 Received: (from maine@localhost) by altair.dfrc.nasa.gov (8.12.8/8.12.8/Submit) id h3UL0loW032688; Wed, 30 Apr 2003 14:00:47 -0700 From: Richard Maine MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <16048.14718.830557.428882@altair.dfrc.nasa.gov> Date: Wed, 30 Apr 2003 14:00:46 -0700 To: sc22wg5@dkuug.dk Subject: Editor's comments on 03-007 X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Sender: owner-sc22wg5@dkuug.dk Precedence: bulk The following should presumably be a paper for Dresden. P.S. I will not be at Dresden, so I hope this stuff stands on its own. -- Richard Maine | Good judgment comes from experience; Richard.Maine@nasa.gov | experience comes from bad judgment. | -- Mark Twain ------------------------------------------ Date: 30 Apr 2003 To: WG5 From: Richard Maine Subject: Editor's comments on 03-007 This paper has the majority of the editor's comments generated while creating the J3/03-007 document. A small number of my comments that seemed appropriate for separate papers are not included here. Comments on papers incorporated into 03-007. paper 03-104r2 [474:2] "may" is not appropriate here; we aren't giving any permissions to the C processor. I'd suggest "might". paper 03-108r3 I don't like the phrase "size in bits of". The "in bits" doesn't fit well between "size" and "of". Makes it sound like the "of" modifies "bits" instead of "size". Adding "expresssed" doesn't help either. Also, the wording makes it sound like the file storage unit size is required to equal the value of the constant. I think this is backwards. We don't have a requirement on the file storage unit size; it is whatever it is. The constant is then required to equal whatever the file storage unit size is. So something more like "The number of bits in a file storage unit is given by the constant...". paper 03-113r3 [42:9+] The first sentence of 4.5.6.1 (which this explicitly references) says that "an extended type includes *ALL* [my emphasis]...nonfinal procedure bindings of its parent type." I see no exclusion for deferred bindings. This appears to contradict what I assume is the intent here. In fact, I think this points up a flaw in our description of tbp overriding. This isn't new to this paper. Although we talk a lot about the conditions under which overriding happens, I can't find that we ever actually say what it means to override something. Apparently it doesn't mean that we didn't inherit it (we needed to inherit it before we can even determine whether or not it is overridden). But does anything actually say that overriding means that we will end up resolving to the overriding one instead of the inherited one? I can't find it. Since an extended type includes all nonfinal procedure bindings of its parent type, it appears to me that if you also have an overriding binding, that both the inherited one and the overriding one are still somehow there (and even are part of the "all" bindings passed on to further extensions). I think we are relying too much on people just knowing what we mean without us actually saying it. A common flaw, I'm afraid. I suspect that what we want to say is that we inherit only those bindings that aren't overriden. We'd then have to slightly reword the material on overriding so that it isn't self contradictory in referring to an inherited binding that it is about to say isn't an inherited binding. But that should be easily solvable. (Just need a term for the binding that might or might not end up being inherited. Perhaps just "the parent binding" would do). Once we say that the parent binding wasn't actually inherited because it was overriden, then I think the rest of the questions go away. [53:30] "abstract type definition" sounds like a type definition that is abstract; i.e. "abstract" modifies "definition". We don't have such a thing. It suggest this would be better as "definition of an abstract type". It striked me that NON_OVERRIDABLE and DEFERRED are almost anyonyms. Too bad their names don't give a hint of this. Alas, I don't see a good fix, as renaming DEFERRED to something like MUST_OVERRIDE doesn't seem like an improvement. The choice of when to cross-reference and when not to seems arbitrary to the point of confusion. For example, we have several constraints in 4.5.4 that talk about overriding, and the *LAST* one of them now xrefs the term. But then again, perhaps lots of things in the document might make more sense if read backwards. :-) [53:31] Again not new to this paper, but the use of the term "binding" seems almost hopelessly confused. We shouldn't have a bnf term if we are going to use the word "binding" to refer to other things. For example, the addition at [53:30] is close after the bnf definition of , but it appears to be talking about something else. When does "binding" mean and when does it mean something else. Apparently a specific binding is a binding, but it isn't a ....or something like that. I've lost track. I think we should use a different bnf term to avoid this confusion. This stuff gets confusing enough without using terminology that makes it worse. This edit brought it to my attention because my first reaction was that a binding didn't have an interface-name, but I then realized than another paper had changed "binding" to "specific binding", which apparently changed what bnf this sentence was talking about, since a is not a specific case of a . [56:11+] Someone once went through and got rid of all the places where we say that examples "can be found", replacing them with more straightforward statements, usually along the lines of "For examples of... see...". Though it doesn't strike me as a big deal, we probably should do the same thing here instead of making it sound like more of a challenge to find. [103:3+] I'm confused about how this can ever come up, but I'll assume that's just because I am indeed confused. Also, the "In a data-ref bits are redundant with the (R612). That's exactly what the (R612) means. But I realize this is copied from the style of the existing constraints. (They should be fixed also.) [415:6+] Did you really mean to xref 4.5.7 here? I'm suspicious of a typo for 4.5.3. But a section labeled "Components" seems a strange enough place to look for a definition of "abstract type", that I think I'll let J3 fix it. Perhaps it will raise the question of whether that's the right place. [418:6+] Do we really need to xref the same section twice in a single glossary entry? Can a dtv-type-spec use an abstract type? Doesn't look to me like that case was caught. paper 03-118r3 [139:9+7] The table ends up pretty ugly with this para in the middle of it. Not wrong; just ugly. paper 03-119r1 The note example of an ENUM definition no longer conforms to the bnf. I could have done the obvious fix, but this points out to me what I regard as a significant technical issue that I hadn't noticed before...but I'll save that for a separate paper. [381:10] This statement no longer appears correct. I don't see how a set of named constants "corresponds to a C type". [471-472] The edits on these pages leave the Fortran code incompatible with the C prototype at [471:1-2]. I could have made the obvious fix, but I'll do it as specified so as to give J3 the opportunity to review it. paper 03-120r1 [387:5+4] Not new to this paper, but my grammar ear says that the "has" in the first sentence of this note (15.12) should be "have" because of the "requires that". paper 03-121r1 [219:19] The "possibly preceded" seems to contradict the "immediately". Also, it isn't clear what the repeat specifier might precede (the P edit descriptor?). Also, If we were going to change this anyway, why wouldn't we just get rid of the arcane part and just say "After a P edit descritor". I can't offhand see any cases that would cause problems. This avoids questions like why it is that the comma is required before an "I" edit descriptor, or a DT one. Why stop at the particular place specified here? paper 03-126 Ok in what it does. But now that you point it out... Why is 14.7 inconsistent with 14.9.21. They both give definitions of what "support" means for ieee_support_datatype, and the definitions aren't the same. Seems best to only say this once, but if we do say it twice, they might at least agree. paper 03-125r1 I generally find "if any" qualifiers obtrusive and better handled other ways (or just omitted). I see that I let two more of them slip by here while my attention was on the technical content. Oh well. paper 03-130r2 I don't think it wise to use the term "specification" here; makes it sound like something that would be in a specification statement. Also it is inconsistent to say, in the [225:30] edit that the input field "is..an IEEE exceptional specification", but then in the next edit ([226:3-]) to talk about "the input field for an IEEE exceptional specification". Is such a specification actually an input field or is it something that has an input field for it? It makes no sense to say "the input field for the input field", which is what I see implied by putting these two edits together. Seems slightly odd that we describe the exceptional cases last for input, but first for output. I find several of the "otherwises" to be ambiguous or confusing; they have a very tacked-on appearance (and I'd say that the appearance was accurate). For example, the "otherwise" added on [226:14] manages to make it sound like it has something to do with scale factor of zero. It is not *AT ALL* clear to me that this "otherwise" covers the next several paras, including statements like that Ew.d shall not be used if the |exp|>999 (which you specify that it will be for Infinities). I'd think that we might want this stuff to apply to infinities and NaNs regardless of whether or not they were the IEEE ones. If the processor supported non-IEEE datatypes that had infinities and NaNs, then I'd hope I/O would still follow these rules, but I suppose that's out of scope of the original request and could be considered an "obvious processor extension". paper 03-131r1 The line for IEEE_SUPPORT_UNDERFLOW_CONTROL doesn't typeset very well in 14.9.1. The macros used don't deal very well when both sides of the table overlow a line. The line for IEEE_SUPPORT_ROUNDING has a similar problem. I think I once before suggested that the descriptions here were overly wordy for a table designed to handle single-line ones. Compare to the one-line descriptions of the intrinsic inquiry functions, none of which seem to need words like "inquire whether". paper 03-138r1 The constraint moved to [52:20+] parses ambiguously, but that problem is inherited from the text in the CD. I'm just noticing it once again. Sounds like it is talking about multiple derived types that have the same generic spec (not that that would make any sense, but that's what it sounds like). [53:21-22] I'm not sure I understand the reason given for this deletion. I wonder whether this constraint perhaps was misscoped and intended to apply to specifics. [53:30+] I think the "may be" should be "is". See comments on 03-177 paper 03-154r3 [24:17] If this is worth saying at all, I'd think it would think would be appropriate to use actual citations of the standards instead of vaguely saying "the relevant standard". We do have both as normative references. I doubt that "the relevant standard" is an ISO-approved citation style. For that matter, since there are two of them, I'd think that at least "standard" should be in the plural. But I suppose perhaps you mean to imply that they are both specified in ISO 10646; that makes it a technical question, not an editorial one. This edit also creates the first place where the usage of the term "this standard" is confusing (it could be naturally read as referring to the ISO 10646 standard mentioned in the previous clause of the same sentence). [40:13+] After this edit we have two consecutive sentences giving two different definitions of the term "ASCII collating sequence". Although the definitions are equivalent, I find this confusing rather than illuminating, particularly since the next sentence then proceeds to use a third style of definition to describe the ISO 10646 collating sequence. Also, the addition of these sentences makes the referent of "these characters" in the following note confusing. That formerly referenced the only characters mentioned in the para before the note. It now is most naturally read as referring to ISO 10646 (the characters now mentioned in the last sentence before the note), which would be incorrect. [141:4+] I think the "the" before the first and the second should be omitted. Usage of the article isn't even consistent within this sentence as is. Our normal usage is to omit articles in contexts like this. [193:14] Did you really mean to allow default character to be allowed for ISO 10646 internal files, but to disallow it for ASCII internal files? That seems inconsistent (and sort of painful). Also, the vagueness of the word "contain" often bothers me, here included. I'd have been happier to just talk about the input items and output items than about what the item-lists contain. We don't mean to prohibit these things from appearing as part of expressions in an item as long as the item itself ends up as an appropriate type. If an item is f(some_string), does the item-list contain an item of the type of some_string? Probably not because some_string isn't an "item", but I'd find this clearer without the word "contain" (since some_string is "contained" in an item). [224:14+] This seems like a strange place to put this material. Some of this seems like it applies to everything in the file - not just data edit descriptors. (Blanks, delimitters, names). I suppose this failing was also in the original, though. Also, I can't quite seem to find anywhere that says that characters are converted on I/O to Unicode files. I see where it says that they have to be something that is representable, but I don't see anywhere that actually says that the conversion is done. Since conversion is *NOT* done for non-Unicode files, this seems like an important point that isn't just an "of course". [210:12+] The explanation of this edit made me think of issues elsewhere. The explanation here says that we want to allow the default to be UTF-8, but we have contradictory requirements that would seem to disallow that. For example, characters of random nondefault types are allowed in default character files, but disallowed in UTF-8 files. Doesn't this effectively prohibit the default encoding from being UTF-8 on machines that have other nondefault character kinds? If a system had only UTF-8 and, say, EBCDIC kinds, with UTF-8 being default character, I don't see how it can implement these inconsistent requirements. [343:13+] You got *EXACTLY* the text from the paper in this example. I'm aware that's not what you wanted, but that's what you got. Whether it is "really impossible" to generate the Japanese characters is not the applicable metric. The editor doesn't know how to do it. If someone (else) can generate images, as has been done in Note 4.14, we can try inserting them here. Also, the editor does not know the appropriate character numbers and does not accept "go figure them out" as adequate editorial direction. The current draft is certainly incorrect here now as a result. paper 03-155r1 [301:27-28] This edit has a construct "x and y and z", which doesn't parse clearly. It is intended to be part of "... x and y) and (z ...", but it is hard to read. For that matter, now that I look more closely, the second "and" should probably be "or" since only one or the other of these can apply - never both. Also, a "then" after the initial "if" phrase would help another parsing difficulty. (Generally, the more complicated a sentence, the more it helps to use a "then" to clearly delineate the end o fthe conditional part; a comma doesn't do it well enough in a complicated sentence). [324:15-16] Similar parsing problems. I find both of the new sentences in this paper pretty hard to read. paper 03-157r1 [268:7] and [405:36] Seems to me that 15.2.1 ought to be a more appropriate section to xref. My first reaction was to wonder why we were xreffing the section about named constants in the module...but indeed the defnition of "C character kind" does appear to be in 15.1.1. IMO that's the wrong place for the definition of that term; it belongs in 15.2.1. [377:0+6] Duplicates an edit in some other paper (which I didn't bother to track down). paper 03-159r2 The first edit expects the reader to be able to parse "x and y and z" as 2 conditions. The intended parsing is that the 2 conditions are "x and y" and "x and z". Good luck in deducing this without already knowing the answer. paper 03-162r2 The "fixes" to 6.3.1.1 don't seem complete to me. I think it would be better to separate the definition of what the allocated and unallocated states are from the list of how variables get to be that way. The 2-item list at the beginning of 6.3.1.1 mixes all this together. This added a few things to the list of how variables get to be that way, but the list isn't complete. Better to remove it than to attempt completing it. The "excuse" that we say something like "as in a DEALLOCATE statement" to describe the deallocation in some other situations strikes me as pretty flimsy. [110:24-25] I find the indirection in referring to "the allocation transfer procedure" odd. For other single intrinsic procedures, we refer directly to the procedure by name. The reader won't guess that you are doing this in case you add another one in the future - he reads the document as is. Besides, if you do add another, you'll need to change this anyway (to be plural). [287:15] This edit is just flat wrong, but I didn't try to reword to fix it. Someone needs to. This explicitly labels MOVE_ALLOC as elemental (which it isn't and can't be). [13.5.14+1] The plural is wrong. Wouldn't it make sense to use the word "moves" instead of "transfers" in the 1-line descriptions of move_alloc? It isn't called transfer_alloc. I don't understand the "remains" in "The allocation status of TO remains unallocated". How does it "remain" unallocated if it wasn't unallocated in the first place (and I see no requirement for it to be). If this is somehow implying that the INTENT(OUT) caused it to become unallocated (does that happen? I forget) and then that it "remains" unallocated after that, I find that *VERY* confusing. Something should say this outright instead of leaving it to deduction. If that's not what it is implying, then I suspect it may be wrong instead of confusing. Also, I'd say that these 2 paras would better belong under the "TO" argument (and the last para under "FROM") instead of just hanging here outside of any subsubsection. [404:29+] I despise this use of the word "certain". In this case, at least, it adds nothing. The sentence would say exactly the same thing without it. Also, I don't think we ever talk about a target being associated with a pointer. It is always the pointer that is associated with the target. Even if you want to argue that the association goes both ways, I find this backwards version very confusing. Since we never (that I can think of) describe it this way anywhere else, it makes me wonder whether you are trying to imply something other that what I assume you mean. Also, the indirect reference to move_alloc here looks especially silly insomuch as we then feel the need to follow it with a direct reference to explain the "certain" circumstances. Might as well have just put the direct reference in the first place instead of making the reader trace through to find that both refs end up at the same place. paper 03-164r1 This paper makes the discussion of TKR incompatibility in C.11.2 awfully confusing, since there now is no such term. I didn't bother to study C.11.2 to determine whether a simple change of the term would make it correct or not; that needs technical verification instead of editorial fixup (and frankly, I've never actually read C.11.2 at all, even to skim it; I used cut&paste to insert it without needing to type or read it). Also "distiguishable with" is horrid. You undoubtedly want "distinguishable from". I almost just did this for you, but you'll need to fix C.11.2 anyway, so I'll leave this one as passed also. After this paper, the acronym TKR appears only 3 times in the body of the document (and a bunch of times in Annex C - some of those presumably to disappear). One of the 3 normative apearances is its definition in section 5. It is then used 2 times, both in section 16. One of those is in the definition of "distiguishable"; another is a few lines further down (and possibly wrong??). I don't think we should define such a cryptic TLA (Three-Letter Acronym) if this is all the use we have for it. If we define it at all, we might want to do so within 300 pages or so of where it is used. paper 03-172r1 The term "different means" in the [180:5] edit isn't defined and is subject to multiple interpretations. Is a module procedure defined "by different means" than an external one, for example? The text added at [392:26+] says the same thing, but more precisely. (Why we attempt to say exactly the same thing in normative text in 2 different places is a separate question). paper 03-173 [265:9-10] In moving this, I had agreed that a note explaining this would be reasonable, but forgot to observe that there is no actual note text proposed. The explanation for this is a technical, rather than editorial matter (I'm not at all sure I'd even get it right), so I didn't try to craft one on my own as editor. Thus I did no edit for this, but I agree that it would be reasonable to do one (given suitable words). paper 03-180 [272:13] The structure of this list has multiple confusions after this edit. Two of the 2 list items have articles, but the other doesn't. I can't quite tell whether "execution of" is supposed to apply to the first item or all 3, but neither option makes sense; I suspect it is somehow supposed to apply to the first 2, but the sentence structure doesn't support such an interpretation. And once that is all straightened out, it will still seem strange that the edit before this adds 2 items to the sentence starting this para, but only adds 1 to this one, making one wonder what happened to the other. Is one of these 3 things still completed if the invocation didn't involve any of these 3 kinds of things? Seems to me that overall, these 2 edits have made the inconsistency and confusion worse instead of better. paper 03-183 E19 - Not new to this paper, but it seems to me that this text (first para of 14.7) is about operations rather than operators. Two places. Also, new to this paper, the first edit talks about "operators of" addition etc., while the second talks about "operators for" addition etc. I think the usage should be consistent (and I think the appropriate usage is "operations of" in both cases). The last sentence of the edit has "x or y and z", which parses ambiguously at best. (If you apply Fortran's rules of precedence to English, then the parsing is just wrong). paper 03-186 [48:3-8] This edit deletes one thing that does not repeat anything said in 2.4.6. I agree that the section on derived types was a strange place to discuss pointers in general (I've mentioned that more than once before), but we should make sure that all the material deleted from here actually *IS* said somewhere else. The missing piece is the mention of the pointer association status of "undefined". The word "undefined" doesn't even appear in 2.4.6; it probably should. The following sentence, deleted from [48-3-8] seems like a good candidate for transplanting into 2.4.6; it's an important thing to say somewhere (and preferably somewhere better than in a discussion of components). "Pointers have an association status of associated, disassociated, or undefined." (later). Oh. I see. That same sentence (almost) appears in 16.4.2.1. Couldn't we tie 2.4.6 and 16.4.2 together a little better? We can't seem to make up our mind which of these sections actually says what. Section 2.4.6 has the definitions (they are bolded) of associated and disassociated, but doesn't have the above even more basic starting point. The only xref from 2.4.6 to 16.4.2. is on a much smaller point and is later. These sections need to agree on which one is going to say what things; and they should xref each other more appropriately. Also, isn't the remaining normative content of 4.5.3.2 (a single short normative paragraph without a lot of meat) a bit slim for a subclause all of its own? The paper describes (and with some justification) the normative material here as "introductory waffle". Was it also noticed that the "introductory waffle" was the *ONLY* normative thing in the subclause? Doesn't that seem a little odd? We do have some subcauses that are composed entirely of examples, but those tend to have titles that include words like "examples"; they don't have titles like "Pointer components", which implies to me that this subclause is actually going to say something new about pointer components. While I'm on the subject, I might say similar things about 4.5.3.1, though at least its para is a little longer. Seems to me that if everything we need to say on a subject organizes well into a single short para, then the para itself is adequate organization, without needing a subclause heading. I suspect these subclauses are developmental artifacts that might have once made sense, but no longer do. paper 03-188r1 [262:28,263:1] Previously passed paper 03-138R1 moved and revised these words in such a way that the merge was not necessarily obvious. Therefore, I didn't do this edit. It is possible that something still needs to be done here. Also, this prompted me to reread the words as modified by 03-138R1 and question some aspects of them. I don't think a binding is "in" a type. It might be in a type definition or it might be for a type, but I don't think it is in a type. Also, this may relate to my comments on 03-113r3. Miscellany not directly related to passed papers The note on pg 41 of the 03-007 had problems printing on many printers. This needs to be resolved. Possible fixes to the printing problem are under investigation. If those don't work outm the nore wil need to be rewritten to use some other exampe. Section 9.10.4 typesets poorly (lines overly long and not readily breakable). It could be improved by minor wording changes that I think an improvement anyway. How about deleting "integer" from items 2-4. It is superflous in that this is the only kind of value a scalar-int variable can ever be assigned. We could also delete the "negative" from items 3-4, as that duplicates what is said in 13.8.3.2, but I can see at least some clarifying value in the redundancy.