07-179 To: J3 From: Malcolm Cohen Subject: Editor's report on 07-007r1, part 2 Date: 2007 March 29 1. Introduction This is the editor's supplementary report on 07-007r1. 2. Thanks I would like to thank Van Snyder for his sterling efforts in entering the base edits from the papers passed at meeting 179, and also for his work on improving the infrastructure (j3.cls etc.). 3. Further editorial changes Modified the "itemize" environment in j3.cls to have the same spacing characteristics as our "enum" environment. This removes excessive spacing in bullet lists. Reworded the first sentence of the Introduction to refer correctly to the standard. "Organization" is not ISO-compliant (there is no such element in an ISO standard). Deleted the heading, making the paragraphs part of the introduction. Changed some lists to bullet lists for ISO conformance. It is also more readable not to have extraneous ordering implications, especially for short lists whose items are never referred to. Unlistified 1.7.6. It did not conform to the ISO directives for a list, and indeed makes perfect sense as ordinary paragraphs, which it is. Deleted the final item of 1.7.6, as it didn't say anything meaningful. (Indeed, if it had any meaning it was probably wrong.) Properly listified the c02 object designation lists (they were junk before). Fixed the list in note 3.10, which was not ISO-conformant. Fixed R502. Fixed note 7.11. Moved Note 9.8 from out of the middle of a list to the end of its subclause. (ISO directives request that notes appear at the end of a subclause unless there is good reason otherwise. There appears to be no real reason here.) Moved Notes 9.9 and 9.10 similarly. I found Note 9.10 quite disruptive to reading the list where it was (and it is unnecessarily long and repeats normative material from only a few lines earlier too, but I didn't change that). The lists in 9.10.1, 9.10.2 and 9.10.3 were ungrammatical. Fixed I hope. Note 9.68 said "Consider the example:" but didn't follow up with anything. Changed it to "For example,". Fixed indexing in c10 to index the whole of C1002, not just the first line. Rewrote Note 10.8 to use "sign mode is PLUS" instead of "SP edit descriptor is in effect", which was no longer accurate. Indexed sign mode both there and where it is defined in c10. Indexed scale factor under "P editing". I note that stylistically c12 is still a bit of a mess. I didn't do anything about it though! Fixed case(iv) of SIGN to be grammatical. Fixed the scoping unit list in Annex A to be grammatical. Why are we still bothering with this hostage-to-fortune junk? [406:25] Typo "that elements" -> "that element's" [464:22+] Added heading "General" for 15.2.3.0. 4. Review of papers from meeting 179 07-103r2 Rewrote the RESULT clause to be more like the others, fixing the grammar in the process ("some" is not an indefinite article). 07-104r1 REJECTED this edit. Folks, this paragraph is about <>. It witters on unnecessarily about what we provide to handle <>. C_SIZEOF has absolutely nothing to do with this. In any case, the standard would be improved by deleting redundant junk, not by adding more. I will consider deleting the whole paragraph next time, especially since it claims to define the term "C address" but does no such thing. Added UTI 111 about the defective definition of "C address". 07-108r1 Deleted the syntax rule reference on the three constraints. It should be obvious to everyone that this was wrong! 07-113r2 Reinstated UTI 092. The contradictory text doesn't stop being contradictory just because you are delaying for an interp request. That would be like "hey, let's delete all UTI because we're not going to fix them this meeting". That is simply counter-productive. Furthermore, the interp is a portmanteau, so unlikely to reach resolution any time soon (better to pick off any problems individually)... but... ...in any case, the interp is not about the contradictory text! If we had an interp which actually contained edits to fix the problem I'd be more sympathetic. BTW, the answer could well be that the answer is not standardised. In a way, that's pretty much what the current state is ... except that it achieves it by contradiction, which is not usually considered a good thing. Finally, F2008 is not constrained by the interp process. FWIW, I intend to write a paper with actual edits next meeting. Whether that gets processed as an interp, an F2008 edit paper, or both, can be decided then. 07-114r1 Reinstated UTI 093. The broken text does not make sense for INF and NaN. It doesn't start making sense just because someone wants to answer an interp later. In any case, the interp doesn't point out that the text is broken. Again, I'll write a paper next meeting. Honest! (If I forget, just tell me...) 07-122 Hmm, I don't quite follow why it is so important to be error-prone (by allowing CLOSE in CRITICAL in a situation that cannot be checked for correctness). Deadlock or crash is not what I'd prefer to get over a compile-time error message. Added UTI 112 about various problems with OPEN as an image control statement. 07-123 I am seriously unimpressed by the arguments in this paper. But it's not worth quibbling over. 07-125 This change (an element or section of a co-array is not a co-array) breaks several things in the standard (why am I not surprised). Added UTI 113. 07-126 Reading this made me realise it was defective (before and now). Unless we have very uninteresting coarrays, since all their bounds must have exactly the same values. Added UTI 114. 07-127r1 Reinstated UTI 086. The paper's claim that "the check burden gets increasingly large as the number of images grows" is false. (Well, one could implement it that way, just like one could implement a DO loop with a weird recursion that required N**2 space and N**3 time, but it is rather obviously not required to be implemented badly.) Furthermore, the "extract the list of images" (and check manually) idea would be massively intrusive - and incidentally *WOULD* cost O(N) instead of O(1), at least without compiler smarts to work out what it was doing and optimise the extra junk away (and such optimisations are typically fragile and unreliable). In any case, with large numbers of processes being synchronised the communication overheads are likely to dominate. Finally, it suggested a compromise of fixing only FORM_TEAM, but no edits, and no rationale for not at least fixing that. Sorry, but I still don't believe silent wrong answers and mysterious crashes are necessary for high performance programming. In fact I believe the opposite to be the case - that high performance is only going to be possible when the programmer does NOT have to be constantly thinking about "what if" and double-checking all the time. 07-128r1 Subgroup wrote that changing it to "processor dependent" makes the facility too difficult to use. Wrong. The facility is INHERENTLY too difficult to use. The processor dependent cases are still going to be there, you've just painted over them. However, computer hardware isn't going to be fooled by the paint, so the users' programs will still fail to work anyway. Personally I'd prefer it if the standard didn't claim things contrary to reality, but I'll give way on it for now. The r0 of this paper said "The argument in the internal note is based on enhancing portability. It is difficult to see how making an action "processor dependent" improves portability. It certainly reduces usefulness." That is totally and utterly false. The action *IS* processor dependent, that is, I don't believe vendors are going to bend over backwards to do what this really implies (all bit patterns are valid for all data types), it is a small matter of having the standard accurately describe reality. It goes on to say "Furthermore, the C lanugage allows such mismatches to a much greater degree that Fortran 2008 without causing catastrophe. For example, consider the void * 'buffer' dummy argument in the wide array of" Again, totally wrong. In fact C99 does not allow this, it EXPLICITLY allows "trap representations", IIRC only "unsigned char" is guaranteed to have no "trap representations". (Use of a "trap representation" leads to "undefined behavior [sic]", which is the C equivalent of "start WW3".) The r0 also states, correctly, that there are some problems with TRANSFER. Indeed so, but that is no reason to add more problems! 07-133r2 Multiple revisions. (a) Edit 1 made the sentence hard to read - greatly simplified. (b) Edit 4 used a forbidden construction ("may not"), and made the sentence ungrammatical. I disagree with the "Prohibits" assertion in the paper, though I agree the wording could be improved. If the current wording was so bad, why did the paper not edit the identical wording in the next two paragraphs? If there is a problem for one, there is a problem for all three occurrences. Reverted. It's a close call, but I don't think this poor wording is quite grounds for a UTI (and it is the same in F2003). 07-135r1 This still appears to be inconsistent, but I'll write another paper for it in my soon-to-be copious free time. 07-136 Ugh. Much too long and complicated, which probably explains why a nonsense statement is in the middle of it. Added UTI 115. (I'm not entirely convinced by the typesetting either, but that's less important.) 07-137r1 Ugh. "always-contiguous" is unspeakably horrid (and misleading). "simply contiguous" would be much better. I'll write a paper later... 07-144r2 Re-instated UTI 100, since the paper (07-144r2) made not even a pretence of resolving the issue. Re-instated UTI 108, since the paper (07-144r2) made not even a pretence of resolving the issue. No folks, it's not ok just to delete things because you don't understand them! It was described (admittedly not very clearly) in the editor's report. I've expanded on the description in the new version of this UTI. 07-149r1 REJECTED the second edit. The paper is factually wrong about the meaning of "determine". This use of "determine" was correct. We use this meaning EVERYWHERE throughout the standard. The word "specify" is incorrect: it is not necessarily *specified* at all (but it must be determined in some way). A quick scan of the working draft reveals one incorrect use of "determine" (not coincidentally, from the same author). I'll fix that next time around. 07-150r2 This seems to be problematic - see my comments about recursive iterative refinement on 06-293. Since in the recursive case the descriptors will be on the stack, with potentially different addresses on each image, I am at a loss as to what this achieves or is intended to achieve. Deferred raising a UTI or anything until I can think about it more (and maybe get more explanation about why things are so bad). 07-151 Well. I disagree quite comprehensively with practically everything said in this paper. "BITS are a performance feature"? Don't make me laugh. And much of the characterisation of my arguments is irritatingly misleading. I will raise this later again at an appropriate time. 07-155r2 "completion step" is referenced in widely separated places and therefore needs to be indexed, or maybe even a defined term. Grr. I really don't have time for this. Added UTI 116. Also, the wording is redundantly duplicative (e.g. for CLOSE). Also, it seems not to achieve a lack of deadlock in termination. Also, do places other than CLOSE need to say anything about it? Added all these to UTI. 07-166 It still looks like we're trying to say stuff that's clearly outwith the scope of the standard. It really would be nice not to do that! It does get us into trouble... but at least it's not a direct contradiction now. 07-169 UTI 084 was *NOT* feature creep, the prohibition against USE in BLOCK was *NOT* part of the original specs, syntax, or edits. In fact UTI 084 was added by paper 06-254r1 because we ran out of time at the meeting to do the edits, which at that time were onerous due to the lack of SAVE attribute on module variables. Now that the edits are nearly trivial (because modules don't "go out of scope" any more), we're not bothering? I do despair. Note to self: raise this one again and again. 07-170 Rewrote from scratch. Yes, I *REALLY* don't have time for this! (Van added it to the wrong list in c09, which didn't help.) It needs to go *before* item 3, not after, and items 3+ are skipped if any of the conditions occur -- check the previous list for wording. At least, that would seem to be consistent. And the faulty item needed deletion (it's unnecessary anyway after the insertion of the new item, assuming I got it right). Reinstated UTI 091: since I rewrote these edits, they need review. I am fairly confident they are what we want, but it probably warrants an interp to make sure F2003 gets it right (currently F2003 has the contradiction?). Also, there is still the small matter of the final paragraph of the previous UTI 091, which was not addressed by the paper. Included that in the new version of UTI 091. ===END===