J3/08-102 To: J3 From: Malcolm Cohen Subject: Editor's Report for 08-007 Date: 2008 January 15 1. Editorial Changes Fixed a random "correspond with"->"correspond do". Termified "unit" (with "input/output unit" as a synonym). Indexed "edit descriptor" instead of "format descriptor", which latter is a term we in fact never use even once in the text. Indexed "scoping unit". Finished indexing of "extensible type". Indexed "program unit" and "block data program unit". 2. Meeting Paper Disposition Summary Table Cut-and-pasted from the minutes and then updated as each paper was done. 07-280r1 0003 07-299 0104 07-313 DONE 07-327r2 DONE 07-281r2 0079 07-300 ~007 07-314 DONE 07-328r3 0108 07-282r2 0080 07-301r1 DONE 07-315 UTIGONE 07-329r2 DONE 07-287r2 DONE 07-302r1 0105 07-316 UTIGONE 07-330r1 DONE 07-288r1 DONE 07-303 ~007 07-317r1 DONE 07-331r1 DONE 07-289r1 s1DONE 07-304r2 DONE 07-318r1 ~007 07-332r1 DONE 07-290r2 DONE 07-305r3 DONE 07-319 DONE 07-333r1 REJ 07-292 DONE 07-306 UTIGONE 07-320r2 DONE 07-334 REJ 07-293r2 REJ 07-307 DONE 07-321r1 ???? 07-335r2 DONE 07-294r2 DONE 07-308r1 DONE 07-322r1 DONE 07-336r1 DONE 07-295r1 REJ 07-309r1 0106 07-323r1 DONE 07-337 0004 07-296r1 DONE 07-310 ~007 07-324r3 DONE 07-338 0109 07-297r2 0102 07-311 DONE 07-325r2 DONE 07-339 0099 07-298r2 0103 07-312r3 0107 07-326r1 DONE 07-340r1 0100 The 4-digit number after a paper number indicates an F03/ interp number. "~edits" means the paper does not contain edits to the current 007 other tha to remove a UTI. "~007" means the paper does not pertain to the current 007 at all. "sect1" means only section 1 passed. ???? = Malcolm thinks this has nothing to do with the 007. 3. Meeting Paper Details 07-287r2: [7:5] Done, though this seems to have little to do with the topic. EXTRA EDIT [14:31] Reworded to put the obsolescent items together and obsolescent-fonted the lot ("ENTRY, or statement function"). Why is there no edit for page 14? [27:28] We don't put "<>" into obsolescent font in this case. [27:30] Ditto. [27:43] Ditto. [31:23] Which of these things is not like the others; the font usage in this sentence is now completely impenetrable (for ENTRY it means that ENTRY is obsolescent, for DATA it means the practice of putting it in the executables is obsolescent). [32] I didn't find "and ENRTY statements", so I just did "and ENTRY". Statements includes FORMAT so would be inappropriate. [32] I didn't find "ENTRY statements" here either, just did "ENTRY". [116:30-31] Also did the following comma. [119:18] Ditto. [153:6] Done. [153:23] Done. [164:23] Done. [288:15] Done. [288] in Note 11.4 Done. EXTRA EDIT: [292:6] \obs "an ,". [295:8] Done. [295:33] Not the initial comma. [296:2-3] Done. [298:26] Not the initial comma. [298:28] Not the initial comma. [299:37] Reworded to put the obsolescent things together. [300:29-30] Done. [326:9] Not the initial comma. [327:14-15] Not the full stop. EXTRA EDIT: [329:22] \obs "or ENTRY". [330:30-332:13] Not the heading. EXTRA EDIT: [338:4,11,14,17,18] \obs-fonted the constraint numbers; this is in the "Statement function". [475:10-13] Done. [475:20] Not the trailing comma. [478:35] Done. [478:37] Done. [485:6] Done. [485:18] Done. [485:26] Done. [494:22+] Done. [495:30+] "Entry Statements"->"ENTRY statements". EXTRA EDIT: You are supposed to tell the user what to use instead, like all the other ones do. If you cannot do that, it is NOT obsolescent. I added a paragraph to do that. 07-288r1: [225:8-10, 17-18] Retained "in the data transfer statement", otherwise the incorrect syntax ref makes it meaningless since a single can't contain both a namelist group and anything else. (It's still a bad syntax ref, but at least the reader can figure out what we meant.) [225:22, 225:37-38] REJECTED. The first sentence of the insertion duplicates part of C913. The editor wonders why the EOR= and SIZE= requirements were not combined, since they are identical. [225:23,225:35-36] REJECTED ditto. EXTRA EDIT: I combined C923 and C924, and paragraphs 2 and 3, with wording of the latter similar to that in the rejected edits. Hopefully this gets close to what subgroup were intending. [229:1] Done. [235:32] Done, but the editor wonders whether stating this in a more positive form might read better, viz "Unformatted data transfer is permitted only for a file that is \termi{connected} for unformatted input/output." [236:1] Done, but the editor wonders about the wording similarly. [239:26-28] Retained the closing full stop. The editor wonders why these three bullet items quote the character value, and not with Fortran quotes either, in opposition to our practice elsewhere in this clause and throughout the whole rest of the standard. 07-289r1 section 1: [260:18] Done. [261:23-25] Done. [261:36] Done. [262:3] Done. [262:20] Done. 07-290r2: [230:19] Deleted "input/output list" instead, since I don't know what an "effective list item" is (that was complaint UTI 141!). [232:1-2,4] Done. [263:14-18] Done. Since UTI 141 said "Please review this" it might have been nice to say whether you thought I got it right. Deleted UTI 140 and 141. 07-292: [64:13] Did the edit (the "definition" is wrong) but... The commentary says "Objects are then covered by 4.5.1p5 at [64:15].", and this is completely incorrect - 64:15 defined *components* of an object, not *direct components*. The paper goes on further to say "The intent is that the term is defined both for types and for objects."; if so, it has failed in that intent. It further says "As is, 4.5.1p4 only defines the term for objects." which is incorrect, it already defines the term only for types, the "object" in the definition is being used referentially not definitionally. Since a quick grep reveals the only usage of direct components being in relation to the type we are probably ok... 07-293r2: REJECTED. If the definition of subcomponent is wrong for here, it must be wrong for everywhere. Certainly in A%PTR%COMPONENT, COMPONENT is ***NOT*** intended to be a subcomponent of A (that just does not make sense). It is a subcomponent of A%PTR but not of A. If the definition of subcomponent gets that wrong, fix the definition. And direct component is wrong here because we are talking about objects not types. 07-294r2: [441:18] Also inserted "assigned the value" after later "is". [442:10] Also changed "the value is" to "it is assigned the value". [442:22] Done. [442:25-26] Done, but this is ambiguous so the UTI is not yet resolved. [443:5] Done. [443:8] Done. [443:19] Done. [443:21-22] Done. Modified UTI 133. 07-295r1: REJECTED. Applying this edit results in a direct contradiction with line 6 on the same page instead of a lie. That's not enough of an improvement to be worth doing. 07-296r1: [11:22] REJECTED reference insertions. These are defined terms. They are defined in clause 2, not clause 12. The references into clause 12 are wrong anyway. Did the deletion. [296:20-21] Done, though I still think it would be better as a note. [297:9] Done. Deleted UTI 139. 07-301r1: [16:9-11+] Done. [95:2-3] Done. [459:7-8] Done. [470:2] Done. [470:4] Done. [470:8] Done. EXTRA EDIT: [471:2] Did the obvious edit. [471:3-4] Done. [471:11] Did "have a name that has external linkage" instead. [471:34] Done. [635] Instead, indexed it everywhere it occurred, and make p459 the defining occurrence. I think we need to mention that we use defined terms from C somewhere though. Deleted UTI 143. 07-304r2: [316:28+] Done. This is much better. Deleted UTI 130. 07-305r3: [317:3-] Done. I note that after the previous paper, these two adjacent notes have very similar examples and riff on very similar themes. They probably ought to be combined into a single note with a single example that makes all the points that need to be made. Deleted UTI 131. 07-307: [467:1] Done. [467:7] Done. 07-306: Now that the authors have explained (via those notes) what they really mean by this I accept that this sentence I was complaining about is not, strictly speaking, incorrect. I still think it is horribly misleading, but I'm not going to spend time trying to come up with wording that explains it better. Maybe the situation with dummy co-arrays should actually be properly explained, or referred to, but enough for now. Deleted UTI 125. 07-308r1: [236:32-33] To get this to work properly, deleted "procedures", "allow"->"allows", and deleted "process" in the insertion (I see no process here, just a facility). Also, I changed the procedures from "UDDTIO procedures" to "defined input/output procedures" everywhere I found it, including here. Seems to work best... [164:20-21] Deleted definition of "defined elemental assignment statement" because it was never ever used. I did a reasonable job of indexing "defined assignment", but 90% of the way through found some indexing for "assignment!defined". Do we really want this? If so, it should be done that way everywhere (this is merely a case of using a different macro). I didn't bother to index "defined operation", partly because in some places I happen to know we use "defined operator" instead. Grr. 07-311: [449:2-3] Done. 07-313: There seems to be a bit of "interesting" design here, quite unlike our other intrinsic procedures in the way it uses the KIND argument. For NEW_LINE, for example, we actually provide an argument of the right kind instead of using a KIND argument to get the one we want. That would seem to be eminently doable for MASKL and MASKR too; just have them return a value with the same kind as I, no need for any optional argument at all. It means if one has a default integer X with value 37 one probably wants MASKL(INT(X,int64)) but that's hardly much of an imposition. [345:LOGICAL+] Done. [393:29+] I utterly reject "BIT_SIZE(M)" as being in any sense appropriate for describing the requirement on I. What is it supposed to mean in the context of IMPLICIT LOGICAL(A-Z)? Rewrote to say what we mean, but it's a bit ugly. We don't have these problems with other intrinsics because these use KIND in a funny way (see above). Done. 07-314: [340:7-9] Done. 07-315: It is depressing to have my main complaint about obtuse phrasing being taken as a request for a technical change. It is ironic that I complained about the obtuse phrasing being used instead of saying that the operation is being applied elementally, the authors reject that complaint and then in the very next paragraph talk about the "elemental" nature of the collective subroutines! The text at question is in Annex B; it is MEANT to be explanatory. Well, I guess we don't want to explain it to the users in the same words we use amongst ourselves then. Deleted UTI 119. 07-316: Thanks for the review. Deleted UTI 137. 07-317r1: [96:21+] Done. [316:24-28] Done. [317:2] Done. Deleted UTI 129. 07-319: [334: 13] Done. [334:30] Done. 07-320r2: [217:12-13] Also deleted "of a program" to make it read better. 07-322r1: [339:18-] Done. [339:19-20] Done with a slight wording change, but it is still a bit complicated ... maybe something a bit more like "On every image of the team, the ultimate arguments for each corresponding co-array dummy argument shall correspond as described in \ref{D2:Co-array}." would be better? (I don't think that is quite there yet though.) I made this sentence a separate paragraph. Deleted UTIs 127 and 128. 07-323r1: [12:6] Deleted "for data" (ungrammatical and incorrect). Why incorrect? Because the cross-team reduction operates using data that is not local to the image (otherwise the result would necessarily be different on each image!). [201:9-11] Done. Is there a competition for the longest sentence? [222:8] Done. [337:15-17] Deleted "for data" (same reasons). [337:18] Done. I'm not entirely convinced this yet has quite everything in the right place, but it is a big enough improvement that I Deleted UTI 138. 07-324r3: [31:12] Inserted ", input/output units," instead (we normally just use "unit" in a context where we are thinking about i/o, but in a few places we use "input/output unit" for clarity; I think it is better here too. [209:12] This isn't a requirement the user has any means of satisfying. Added UTI 144. [215:5] I really don't like this blanket statement, but it's probably ok. [217:16-19] Didn't delete "to the unit". "is of"->"has". [222:14-17] This seems to make note 9.23 bad; inserted UTI 145. Deleted UTI 142 (though without careful reading it is not quite clear how you have gotten away without needing units to become image-associated on OPEN with a connect team). 07-325r2: [265:35] Done. [265:37-38] Done. Thank you for giving the actual \ref! [265:41-266:2] Done. [266:3] Done. [266:7-9] Done. [266:9+] Done. [266:10-11] Also deleted ", respectively". [266:19-20] Done. [271:1-] Done. Added UTI 146 because of the quiet change in the semantics of BOZ editing for integers (they did it on the value before, not on the internal representation). Deleted "denoting ..."; this is either completely content-free or a contradiction. Anyway, what it is that an output form "denotes" isn't something within the remit of the standard. For all we know it might be denoting machine poetry. 07-326r1: [56:15-57:9] Called the new subclause "Binary, octal, and hexadecimal literal constants" instead. We don't ever use the made-up word BOZ so used the syntax term instead. Reworded the original sentence that implied only hexadecimal constants were BOZ. It is annoying that we have thrown away centuries of maths in favour of reinventing the wheel, badly. There was absolutely nothing wrong with the previous approach. A pity also that people insist on putting philosophical garbage about having "no type" in the standard. No, the fictions about subroutines and class(*) are fictions with a purpose, and have a standard effect. This philosophical nonsense doesn't, and is just false -- does noone know type theory? Inserting all this counterfactual nonsense, reinventing positional arithmetic notation, just makes us look like a bunch of ignorant dinosaurs. [57:3] Did this very bad idea. [57:5] Ditto. [57:6-9] Done. The only edit in this paper that was actually useful. 07-327r2: This is just so silly. A lot of work that achieves almost nothing apart from obfuscation. I really resent working to make the standard worse when there is no functionality being added. [110:26] Done, the only useful edit in the paper. [110:31-33] Done, a complete waste of time and energy. And why did you ask me to delete the first sentence and type it in again? Perhaps you think I have nothing better to do? Please DO NOT DO THIS AGAIN in future. (Yes, I have to go through and convert J3-notation into LaTeX, it is not a simple cut-and-paste, so this was an exercise that could only result in errors not in any improvement.) [386:26-28] We've just been through the ridiculous exercise of saying that a bit pattern "has no type" (sic), so how can we use it now. ("If false" implies everything including other false statements.) Furthermore, the interpretation of the value in F2003 is *NOT* processor dependent. We do not have a mandate to remove F2003 facilities. Added UTI 149. [411:25] Done. 07-329r2: [342:Table 13.1] Done. Could we not have put these in with the other functions that have special needs? [358:26+] Slightly edited. Did by cut-and-paste, so I hope there were no wording changes other than the conditions between these. These are all missing (the required) examples. Added UTI 150. 07-330r1: [382:18-21] Done. [384:34-385:1] Done. [386:33-36] Done. [371:14-18] Called the shift argument SHIFT like it's supposed to be. [371:27-31] Called the shift argument SHIFT like it's supposed to be. [371:19] Done. [371:32] Done. [382:22] Done. [385:2] Done. [386:37] Done. [371:21+] Done. [371:34+] Done. [397:34-398:2] Simplified MASK requirements. Why is this function not 3-way symmetric with regards to its type requirements? [398:3] Greatly simplified conversion statements. [417:9] Done. 07-331r1: [229:27] Done. Hopefully this edit was chosen because we got the definition of "variable" right, not because we want to read functions from a unit (I didn't check). Deleted UTI 132. 07-332r1: [436:16] REJECTED. This repetitious repetition of the exactly phrasing of the sentence before, which is what this is talking about, adds nothing I can see other than ink and enhanced difficulty of comprehension. Especially since we repeat that "kind of real" at the end. [436:17] Done. [436:18-19] This rewording achieves precisely nothing. Done anyway. [436:23] Achieves if not nothing then certainly only a subnormal (it was implicit before). Done anyway. [436:24-26] Done. None of this has addressed the main topic of 135, and the text remains contradictory. Modified UTI 135. 07-333r1: It seems to have passed by the authors of this paper that we are not editing the IEEE standard and its terminology is not our own. It doesn't help that they misquote it (hint - "add" is not an operation). As for Note to editor: The 1985 IEEE standard uses "<->", not "between... and..." or a double-arrow symbol. it is a complete irrelevance what typographical conventions the IEEE 754 standard used (they aren't going to be used in 754R even!). REJECTED. This paper contains technical changes which are certainly not mandated by WG5 and which do not even make sense. I know there are some people that think that NaN/Inf/subnormal values are the only ones of interest (a few others include "negative zero") and that normal numbers do not matter, but that is not a viewpoint I can agree with. The inserted paragraph says that our intrinsic SQRT, ANINT, AINT, INT, MOD functions all have to obey IEEE for the above special values. It is ridiculous to allow SQRT(2.0) to return 1.4 (not a very accurate result) but to require SQRT(2.0E-37) to return the EXACT IEEE square root. Why did we bother to have IEEE_SUPPORT_SQRT then? Since this paper does not call out this TECHNICAL CHANGE, and has no passed specifications, I am assuming that this was inadvertant. 07-334: This wasn't processed at m181 because the existing text, though admittedly confusingly written, got things right in the presence of ENTRY and internal procedures... and it was less than clear that the suggested replacement did that. I would be more enthusiastic about this change if there had been any mention of these concerns and whether they were misfounded, or had been properly taken into account. REJECTED. I got as far as the third edit before finding it obviously incorrect. (An ENTRY statement does not specify the name of a subprogram.) This does not alleviate my fears about it breaking existing text. Sorry, but I am sending this back to subgroup for further revision. 07-335r2: [56:5] Done. This is somewhat redundantly worded, but since the whole thing is completely silly (just using standard maths we only need three sentences max to get the whole effect) I've not bothered to wordsmith it. [339:21+] Oh really. Couldn't a better title be thought of? [340:3] Done. [340:5+] Sure, but we already said we were talking about nonnegative. [340:11+] Did some obvious fixups (like the broken list, extraneous unnecessary words). Didn't fix all the bad wording though. And what about DBLE and CMPLX - does this not apply there? Added UTI 148. [465] Deleted Note 15.9 instead. BITS is never coming back with the \bits LaTeX macro, since meeting 182 made incompatible changes to some of the bits intrinsics. (Up until that point I had intended to keep \bits in parallel, but with the incompatible changes I have given up.) [568:5+] REJECTED. This is already completely covered by line 5 (we don't go into *ANY* detail on *ANY* of the intrinsic function stuff here, we just punt the user to c13). If there is anything that is not covered, I bet it doesn't just apply to negative integers. 07-336r1: [342ff] Done. [427:9] Done. This is inconsistent with the meaning of "intrinsic". Added UTI 147. [427:11] NO ONE THOUSAND TIMES NO. Presumably the whole point of making this intrinsic module "nonintrinsic" (ha!) is to reduce its importance and visibility. So you DON'T mention it first. Added as a second sentence instead. [430:27+] Did random editorial fixups. The proposed table title is ridiculously long - shortened it to "functions with special needs". ===END===