J3/01-382 Date: 27 Nov 2001 To: J3 From: Richard Maine Subject: Editor's comments on mtg159 papers Insomuch as I probably won't be able to make it to meeting 159, the following are my comments on the papers in the premeeting. paper 01-350, Fix up Intro (again) I think the words as is are better than this fix. The proposed new words have two problems. 1) Insufficient qualification of "extensible and extends". If you want to talk about these, you need to say what they are (keywords). That isn't obvious from context here. Actually, I'd think it better to talk about concepts than keywords here anyway. Possibly just "Extensible derived types" - that is a concept. But if you do want to list keywords, we need to label them as such; otherwise the sentence wants to read with those just as English words - and it doesn't make any sense that way. 2) Irish bull (misplaced modifier). Derived types don't provide inheritance. Presumably the parenthetical phrase is meant to modify "extensible and extends", but it isn't after them. paper 01-354, Comments on Section 4 ok paper 01-355, Comments on Section 5 part 1 ok except for 73:6-7 [73:6-7] I think this edit misses the point of the constraint. But on examining it, I see a more basic flaw. I can find nothing that establishes any relationship between the term "assumed-size array" and the bnf assumed-size-spec. This really needs to be explicit and complete in *BOTH* directions. I believe that the intent is to say that an array declared with an assumed-size-spec is an assumed size array, but nothing ever says that. It is *NOT* obvious from the terminology. In particular, with that plus the definition in the first sentence of 5.1.2.4, it can be deduced that an assumed-shape-spec is allowed only for dummy arguments. I'd add a constraint to that effect. When I say both directions, I mean that it needs to be explicit both that an assumed-shape-spec is used to declare an assumed-size array (which we already say is a dummy argument), and that an assumed-shape-spec is not used for anything else. If you just say that an assumed-size array is declared with an assumed-size-spec, that does not imply that something else couldn't also be declared with such a spec. That would leave open the interpretation that something that wasn't a dummy argument could be declared with such a spec. Given the fixups mentioned above, consider what C549 is trying to do. I think Van misses the point when he says that it doesn't cover result variable names. A result variable is never a dummy argument, so we don't need to cover it separately. It is far more basic to say that assumed-size is allowed only for dummy arguments that to say that it can't be used for one particularly obscure thing that isn't a dummy argument. I believe that C549 is about function dummy arguments - that is the one case where something can be both a dummy argument and a function name. In that case, it is always the function name that is relevant - not a result name. part 2 [73:8, 74:18-25] No, I don't think they should refer to syntax rules. From heated debate about a separate question, I deduce that Malcolm might disagree with me here, but that's still what I think (and my deduction might be wrong). [76:10] Darn - I recognize that as a case of a particularly annoying Frame bug that keeps slipping in. Need to figure out what those were supposed to xref. Or perhaps just delete the line as superfluous. Looks like a holdover from when we felt it necessary to tie constraints to syntax rules. If we do want to say it applies to particular rules, use our new syntax instead of writing it out like this. paper 01-356, Comments on Section 7 part 1 ok part 2 [115:9-12] I'm dubious. The relevant part of the bnf for primary is just , which would be the pointer. Yes, the target gets referenced, as this para is saying, but it looks to me like the bnf does identify the pointer as the primary. [119:37-38] Perhaps better to delete the sentence. I'm not sure what it is trying to say that isn't a tautology. We have rules on how to determine the type of an expression - we don't need to point out that things that aren't in those rules don't affect them. If the sentence is supposed to be clarifying things, then it ought to be less subtle. As is, it relies on the subtle distinction between "depending on the arguments" vs "depending on the evaluation of the arguments". The type of an expression can trivially depend on the arguments. That's what generic functions do. If this sentence isn't actually saying something normative, I'd suggest deleting it. Clarifications that aren't clear don't tend to be helpful. [135:40-42] ok paper 01-357, Comments on Section 9 part 1 [168:16] ok [192:3] and add the period at the end of the next line. [204:6] There *IS* a period at the end of the sentence, but the end of the sentence isn't on that line. Do not put a period at the end of the sentence fragment up to that line. parts 2-3 no comment part 4 I'm indifferent as to whether we delete the restriction, but I don't like the wording of the proposed note. Mostly the "should only be done with care" part. Is this implying that other programming should not be done with care? paper 01-358, Comments on Section 10 part 1 ok part 2 [216:2+] I think this is an artifact of continuation. [217:42-44] There is no contradition here. A and G are not character string edit descriptors. See R1019. [217:23+] The page ref appears to be wrong, but I can answer the question anyway. Yes, the asymmetry is intended. I'm not sure what else you would have in mind, but I don't think we should be trying to redesign this. [226:41+] Possibly, but I don't understand why you note this for subclause 10.10, but not for 10.9, which starts with almost identical wording. part 3 It is an oddity, but I don't think this the time to address it. The oddity has been there for 25 years - doesn't seem to justify being addressed as a "last-minute" feature. paper 01-359, Comments on Section 11 ok paper 01-360, Comments on Section 12 part 1 [239:4-6] The definitions proposed are vague enough to be harmful instead of helpful. We do have quite a few other cases of the "definition by similarity of wording to a bnf term" that this paper objects to. It might be good to fix them, but only if the fix improves on the definition. Lots of entities can appear in a procedure reference without being actual arguments. There is the procedure name for a start. And entities in expressions. Likewise, there are names that appear in function statements that are not dummy arguments. I could go with either fixing this or leaving it alone, but please don't "fix" it to be wrong. If this came to me as is, I'd have formerly done an unresolved issue on it. But since I've voiced my concerns here, I'll assume that if it still passes as is, that J3 really meant it. [267:37] Is not proc-target also a possibility here (for a dummy procedure pointer), or can that not happen for other reasons. ok on the rest of part 1 part 2 I think we already had an interp that answers these with the answer "no", though I might be confusing it with a related issue. Still, the issues are related. I think the interp I recall said that a generic could have specifics with pointer dummy args - you just can't have another specific disambiguated by the pointerness. Perhaps here also, it might be that you could define an operator that only worked with pointers; you just couldn't also have an operator for the nonpointer case in the same scope. paper 01-361, Comments on Section 13 parts 1 and 2 ok with the following exceptions [272:4+] Hopelessly confused. Better to not say at all. It takes subtle reading to understand that you are talking about passing a dummy argument of some other subroutine as the actual argument of the intrinsic. It can be deduced, but clarifying notes that require that much deduction probably don't clarify much. The result is never named DIM (misplaced modifier). The phrase "prohibited to be" sure sounds strange to my ear, though I can't say it is wrong - almost sounds like UK English. [272:16-19,21] I think it better as is; I don't find it confusing. I think the assumed-size array case is important to call out, so I don't like omitting it. But I think the other cases are adequately inferred from what is already there and just look redundant. I think the original better than either of these alternatives. [283:23] The article isn't needed - we have *LOTS* of cases of referring to bnf terms without articles (though we aren't 100% consistent). But it doesn't really hurt either, at least after the other correction. It would have hurt in front of just plain . I'd omit the article, but if J3 puts it in, I'll do it as specified. [286:30] Agree that the existing text is problematic, but I find the replacement complicated and confusing. All the "as if" stuff leaves one confused as to whether it is the original x or the "as if" one in aimag(x). Wouldn't it be simpler just to say that the result value is x converted to the specified kind, instead of going through multiple "as if"s? [288:7] Already fixed in 01-007r4. (I realize this paper was done based on the r3). [288:30] The units of cpu_time are so specified (as seconds), but that doesn't change the substance of the edit. For the first edit, we should use the standard's term, which is neither "computer" or "system", but "processor". I realize that the term is subject to confusion - perhaps we should change it globally, but in the meantime it is the term that the standard defines and we should use it instead of randomly using different ones. Agree with the second edit. [308:26,30] I think it ok as is, the article "a" here does not imply that the array has only one lower bound, just that we are talking about any one of them. But the edit is ok - just not needed (IMO). part 3 I have no real objection to making get_command_argument and get_environment_variable elemental. But I thought we had already settled that question. In my original paper on command-line stuff (97-153), I said (the proposed names were a litle different then) Note: as defined here, get_system_argument could conceivably be elemental. That might possibly close some future enhancement possibilities, though. Any opinions on the advisability of making it so? ... Note: Get_system_variable could also conceivably be elemental. I wouldn't expect its elemental properties to be much used, though. Opinions? As I recall, I got responses ranging from indifference through opposition - none positive. That's part of why I dropped it from subsequent versions of my paper. I do object to making get_command elemental because I can see absolutely no use to that. The only "increased functionality" appears to be the ability to get back multiple copies of the same data. I can't imagine this ever getting used except as an excercise in obscurity. It will just confuse people if they ever try to think about what the implications of its elementalness are. Most of the rest seem like mte requests that I consider out of order at this date. (Command_line args were already on our plate, so tuning them up is in order and is just a matter of whether we do or do not want to make the change). The result definition proposed for huge of a character is defective for non-default character kinds (trivially repairable). And I'm not 100% sure that this is consistent with prior interps relating to the requirements on character collating sequences. Perhaps it is, but I'm not going to waste my time researching it for the sake of an mte that is out of order anyway. I know of no implementations that have the problem addressed by the ichar proposal. (I know of no standard-conforming implementations that have 16-bit default integers. There are implementations with switches to make 16-bit integers the default, but none of them are standard-conforming in that mode.) The proposals for merge and product are just plain new mtes with no obvious relation to any work item. I think them out of order and haven't really examined them in detail - that's part of why they are out of order - because otherwise, everyone has to take the time to study them. part 4 [288:13] Why would you even think an interp was needed? This is *EXACTLY* how we specify that any real kind is allowed. We do it all over c13. The answer to such an interp seems obvious. I suspect that we did intend it, but regardless of our intent, it is unambiguous (unless you consider every other case of the same phraising in c13 to be ambiguous), easy enough to implement, and of at least concievable use (for higher precision). I would consider it inappropriate to make an incompatible change in something that seems so unambiguous and has no obvious benefit to changing. [286:42+] There is an example of command_argument_count in the command_argument section (it seemed like a more informative example to show a code snippet using them together). The command_argument_count section could concievably have an xref to that example. paper 01-362, Comments on Section 14 part 1 ok with the following exceptions [333:8] Also wouldn't hurt to add "in a scoping unit" so that there is a referent for "the scoping unit" in the next sentence. [334:13,18,28] Disagree. Undefined is not a value, valid or not - it is the state of not having a value. These are the only possible values. Whatever result you might get from an illegal reference to an undefined variable is not its "value". [338:4-5] Disagree. All the descriptions in the table are redundant. The table's main purpose is just to list which intrinsics are in which module. That doesn't mean we sould find and delete all material duplicated in the descriptions. Why pick on IEEE_SUPPORT_STANDARD to be the only (I think - didn't check) procedure in the modules to have no mention anywhere in the text except in these tables and in 14.9. (I did check that part - easy to do with grep)? That seems needlessly inconsistent. [338:7-8] This section (I mean subclause) is more like 13.7 than 13.5. Speaking of which I see that 13.7 also uses the word "section". Probably both cases hould be changed to "subclause". 14.8.1-5. Possibly, but I'm not convinced. The names and descriptions in 14.8.1-5 tend to be longer than those in 13.5.1-17. Putting the 14.8.1-5 ones in simillar columns is going to make for a lot larger fraction of the lines with continuations. I can't tell for sure without actualy doing it whether this will look better or worse; both seem possible. Perhaps might be better if the descriptions in 14.8.1-5 were rewritten to be shorter (which is clearly possible in several cases). Abbreviating the names is not so doable (we are already committed to the actual names unless we have a lot better reason for change). [342:24] Agree that the proposed change is an improvement, but is it enough. Might it be better to just delete this note (and 14.8) as being incorrect. I thought we had a simillar discussion of some other topic recently. Seems to me that the result can be "used" in several other ways. It can be the rhs of an intrinsic assignment. It can be passed as an actual argument. It can be in a structure or array constructor. I think this better left unsaid because I think it is wrong. By the time we define what we mean by "used" precisely enough to be correct, the note will be far bigger. It's not as though there is anything subtle being explained here. If we want to point out the connections, perhaps delete the "only" (from both notes), in which case the "validly" wouldn't be appropriate. Though the examples look suficient to point out these connections. [342:34] I only see one case on this line. Don't know whether this is from copying the edit from one of the other cases or whether a secnd line was omitted. I didn't spend time looking for likely candidates for another line. [347:19] Note that this is a technical change. I agree that it seems an appropriate one, but it ought to be pointed out to JKR in case he wants to do something about it in the TR. [350:4-5] The original seems arguably better. The suggested change omits mentioning that this applies only to IEEE kinds. I'm not hard-over either way here. [351:25] Almost said I couldn't find it, but then I saw what's probably it on line 29. part 2 I think these edits are ok (didn't check every line, but I got the general idea). Just please make sure it is adequately agreed before I change them all. I'd be pretty annoyed if I ended up having to change them all back because this got passed without anyone actually thinking about it (something we are prone to do), and then it got changed back the next meeting. Check with Dick Hendrickson - I think he might have had a hand in this wording. no comments for now on part 3 paper 01-363, Comments on Section 15 ok on part 1 part 2 [355:18-19] That's certainly what it says. Note that without this, portable programs would be required to use "USE only" for these modules or be in danger of being invalid because of a name conflict with some additional vendor name. I interpret this as saying that vendors can't add extensions here (unless they have a compiler switch or some way to disable them so that programs conforming to the standard do compile). Of course, f2k+whatever could add extra stuff (and that would belong in the list of incompatabilities in clause 1). [358:11-12] Agree. [361:28] I think the C-ism for this would be that the dummy was a pointer - which we can handle as a data object of type c_ptr. Note that a bind(c) procedure is valid as an argument to c_loc. Of course, we don't have a way to dereference c_ptr, which does make for limitations, but that's a broader issue than just c_ptrs to procedures. paper 01-364, Comments on Section 16 part 1 I generally like the re-organization. I think it is a needed improvement, with the following exceptions. [365:3] Presumably means "If" instead of "It". [365:4-6] What happened to the "or part of a statement" bit; it seems to have disappeared without justification. Just an accidental omission? [365:8-13] I don't find the term "pending data transfer identifier" in 9.5.1.8, 9.6, or anywhere. I don't think it helpful to use the term here and then xref to sections that don't actually define such a term. If we decide that we need a term for such a thing, then the term ought to be defined somewhere in one of those xreffed sections. And simillar comment about "external input/output unit identifier" in [365:8-13] and [366:11+]. I think we should use terms consistently instead of inventing new simillar terms. Grep doesn't find a single case of "unit identifier" anywhere in the document. [366:11+] I'm guessing you mean to add this after the note instead of inside it. Please clarify just to make sure. [366:20+] "generic identifiers" are already in class 1, so don't add the again. And for heaven's sake don't take them out of class 1, as words elsewhere specifically refer to class 1, so you'd change their technical meaning by editorial rearrangement here. (Hmm. Grep only finds 2 instances of "class 1", both in 16.1.3; I thought there were more). [366:44+] This one is "obviously" meant to be after the note. But just in case I'm having a really off day when I enter it... [367:12] Can we make this title a little more concise? At its new level, it will end up in the table of contents, where its length might be annoying. And for that matter, I note that intrinsic procedures are not local entities. So perhaps this whole section belongs under global entities, since the one common (no pun intended) element of the section is a global entity. [372:34-41,373:1-13] I guess that the operator and assignment symbols and dtio-generic-spec are covered as "generic identifiers"? If that's not it, then I don't see where. part 2 ok except [367:24] I wouldn't call it a restriction on the procedure declarations either. [370:35,36 and 371:10] I've never been able to follow this whole section (16.1.2.4) anyway; presumably someone else can. I'll assume that whatever passes makes sense. (Don't count on me to fix it if it doesn't). [371:26] I'm having a little trouble following this. Maybe I've been staring at this stuff too long. I guess other generic specs are already covered? When I see a sentence that specifically mentions some cases, I tend to wonder about the others. And the wording of the sentence could use improvement. Sounds like it is talking about a particular scoping unit ("the" tends to imply that). Something like the word "all" perhaps should be in here somewhere. Not sure I can write better words at the moment, but I find these ones confusing. [372:7] I believe that rank is also an attribute, so they have the attribute of being scalar. That probably should be said. [376:8] Well, yes the cited 2 places are inconsistent, but you chose the wrong one to fix. We use "associated with" instead of "associated to". You found one of the 2 cases of "associated to" in the entire document to cite; the other case is a few lines lower at 376:12. Both are in the same bit of fairly recently added text. We should fix these 2 cases instead of changing all 188 cases of "associated with". (Grep might have missed a few because of line breaks, but I think this enough to make the point). [376:18+] This note doesn't make sense if the selector is an expression. Needs some qualification. [376:25:34] The reference to [375:31] is presumably a typo for [376:31]. [377:6,11] These come from f95. Are they f95 errors? [377:25] No "and" on that line. Perhaps typo for [377:22]? 2nd mention of [373:38] (after the edit for [379:29]). Agree, but you already said this once. Might you be referring to [380:32] for this one? (Based on that being a candidate that is between the edits before and after this one). [384:45] Need to change "variable" -> "variables" also. And I've never liked our occasional (and inconsistent) use of "if any". Going plural here makes it more awkward. How about deleting the "if any" and instead changing "the variable" to "any variables". part 3. [365:7-13] *ANYTHING* is an entity. That was the whole point of the term; its what you use for something that isn't in one of our more restrictive classes of thing. We use the English definition instead of some special technical definition. I still think it a mistake to have even attempted to list the kinds of things that we happen to refer to as entities. Its not like the list has any recognizable patern or coherence at all. Failing to include something in that list is not supposed to mean that it isn't an entity. Why in the world would anything not be an entity? if you can see any pattern that defines what kinds of things would be included or excluded from being entities, then you must be a lot better at those parts of IQ tests than I am (which could well be the case anyway :-)). [378:22-23] I think this ok as it stands. The standard specifies requirements of programs (not processors) unless specified otherwise. Nothing here specifies otherwise. So this just means that the program cannot assume that they are the same. Conceptually, they are different storage units, even if they happen to occupy the same amount of physical memory. After all, character and numeric storage units might also happen to be the same size (if you have 32-bit characters, for example). I see nothing here that puts any requirement on the processor. Quite the opposite - I read it as implying that the processor can do darned near anything in terms of storage usage for these different kinds of things. paper 01-366, Comments on Annex B ok paper 01-368, Issue 344 et al. ok paper 01-381, pointers and C interop Not much specific in this paper. Let me just go on record as saying that I support the latest version of John Reid's paper. It is my understanding that another J3 paper on this subject was under preparation, but perhaps not until the Feb meeting because its proponents might not be at mtg 159 to defend it. It's also my guess that this will come up in public comments if we don't do something about it before then. I haven't yet reviewed papers 01-365, 01-367, or much else after 01-371. Perhaps I'll look at those later, but I really need to get this paper out. It's already late and I may not be able to do any on it for another few days.