07-176 To: J3 From: Malcolm Cohen Subject: Editor's report on 06-007r2 Date: 2006/12/28 1. Introduction This is the editor's report arising from the papers passed at meeting 178. 2. Papers passed directly to /EDIT These were: 06-292, 06-299, 06-300, 06-301, 06-312, 06-315, 06-316, 06-324, 06-355, 06-364. The responses to these are included in 07-101. 3. Passed papers that have been entirely rejected. Papers 06-298r1 and 06-337r1 have been rejected in their entirety. See the detailed comments for details. 4. Detailed comments 06-296r2 -------- [131:12] Done. [137:7+19] Done. [137:7+27-28] Done. [141:33] Also changed "result"->"expression" at line 31. [142:4] Inserted "or BLOCK construct" instead. [145:11-12] Done. [145:13-15] Done. [145:16-17] Done. [146:1-2] Done. [146:6-7] Done. [148:3-6] Done. [148:7-8] Done. [150:20-22] The editor disagrees that the second sentence of this paragraph belongs anywhere other than the bin. That's where I put it. ASIDE: It's not merely good enough to remark that things are "independent" in normative text. In a note it's ok. As normative text it is not specifying anything (not the lack of requirement and the lack of semantics). Since the interpretation, type, type parameters of all operations and operands are specified by the standard, saying that these are "independent of ... context" is blather. [154:12] Sentence had other problems, so reworded more extensively. Also corrected the following table to use b1/b2 instead of x1/x2. [157:12-13] Rejected; the editor considers the cure worse than the disease. ASIDE: The right cure is to extract these arbitrary restrictions for coarrays and coindexed objects and list them separately. [157:21] Added "is not a co-array or co-indexed object" instead. [162:25] Done. [164:4,11] Done. 06-297r1 -------- What an irritating waste of time; the IEEE standard already says everything that needs to be said on this matter. Furthermore, this insertion here makes the subclause format inconsistent with the rest of the clause. 06-298r1 -------- REJECTED. This paper makes an incompatible change to the language. It isn't "correcting" a "problem", it is making a technical change. This is probably inadvertant, since it doesn't attempt to make an entry in the list of incompatibilities. 06-303r1 -------- [10:37+] Done. [11:24+] Did it in alphabetic order instead. Also put endfile into alphabetic order. [11:50-51] Did it in alphabetic order instead. [12:23] Also inserted the necessary comma. [13:14] Done. [13:18] Replaced by "separate module" instead, because non-separate module procedures cannot have their interface so specified. [14:11+2-3] REJECTED. The edit as written doesn't quite make sense. In any case, the new version would seem to be incorrect or even more misleading than the old version. Lots of things affect the "progress of execution", including i/o, even without ERR= branches (which are not control constructs). And image control statements affect the progress of execution within a single image. I think this note needs to be torn up and rewritten from scratch, or just torn up, not patched. [14:19-19+4] Done. UTI 095 removed. [16:16] Done. [18:13+4+] Inserted the correct term instead, inserted a better description, and inserted it alphabetically. [20:8] Done. [20:21] Done. [23:1-3] Done. 06-304r1 -------- [25:26] Done. [34:29] Done. [35:30] Also removed all but one of the indefinite articles in this list, and alphabetised it. Also did a similar edit at line 27. [36:30+] Done. [36:38] Done. [36:39+] Done. [37:1+] Done. [414:6+] Done. 06-305r2 -------- [488:11-12] REJECTED. Repeat after me, folks "a BLOCK construct is not a scoping unit". (So host association is not relevant.) [183:10,23] Removed all but one of the indefinite articles in each constraint, and alphabetised the lists. [189:5] Also alphabetised. 06-306r4 -------- [296:9] Done. Switched intrinsic and module procedures in the list. [311:2] Done. [311:4] Done at [311:5] instead ("dummy argument" is split across 4-5). [311:6] Done, with a complete rewrite, splitting each case into a separate paragraph. [311:10+] Inserted as 7+ instead, to keep the nonpointer cases together. Substantially reworded to improve readability. [312:3-5] Done. [315:31] Done. [318:5] REJECTED. Unreadable, unnecessary given what I did with [318:6+]. [318:6+] Instead, added a single phrase and a single sentence to the paragraph at 5-6. [333:2] Inserted alphabetically instead. 06-307r2 -------- [41:12-16] Corrected missing comma and pluralisation (twice). [41:20-21] Also "though it may have" -> "if it has" on line 23, and "may"->"can" on line 26. [41:29] Done. [41:32] Done. [42:16] Done. [43:15-20+2] Done. [43:24-26] Done. [53:17] Done. [53:20] Joined with a comma instead of "or". [60:5] Done. [71:6] Inserted indefinite article after "in". Made no insertion into the new Annex, as the text already there covers it adequately. [74:1-5] Done. [80:17] Done. 06-308r2 -------- [83:4] Also changed "attributes"->"properties" on line 3. [85:3,4] Inserted "or BLOCK construct" instead. [88:2-3] Done. [88:6-14+3] Inserted "provided that" instead. Left the final full stop as is. UTI 011 removed. [88:22+6] Done. [91:12-13] Done. Probably better to omit "if it is a dummy argument,". [91:14-15] Done. [91:17] Done. [94:13+1-3] Done. [95:0+21-23] Done. [95:14-96:1,2+] Done. [110:4] Done. 06-309r1 -------- [116:6-8] Done. [120:19-21] Done. [121:12-13] Done. [125:10,14-15] Done. [126:26+1-2] Done. [128:7-8] Done. [128:13] Done. [128:15] Done. [128:16-17] Done. [128:24-26+7] Moved [128:20-26+7] instead, 20-23 are also about coarrays. 06-310 ------ [125:20-21] Split the co-array sentence into a separate constraint, reworded slightly to improve readability. [126:18] Done. [126:27-] Reworded from scratch. [127:0+1-12] Well, I've deleted UTI 081 even though the paper did not answer its first question. However, I inserted a requirement that a pointer or allocatable be associated/allocated respectively, as that seems to be the general consensus (and was advocated by 06-313r1 -------- [168:33] Done differently. I inserted instead, with a constraint to make it integer. We don't want extra syntax flying around for type specifiers. [487:10] Done much shorter, since already has the correctly defined semantics, we don't need to repeat them. [487:12] Changed "; it" to ". It" but no other change. The sentence the edit wants to insert is ambiguously worded, and unnecessary to boot since it already follows from implicitly typing the thing plus the rules for IMPLICIT NONE. 06-317r3 -------- [220:7-10] Added a missing comma to the first sentence. Also fixed missing indexing of TEAM= specifier for this subclause. [220:10+] Done. [221:17+] "status"->"disposition" ("status" might mean file status, and the STATUS= specifier in CLOSE determines the "disposition"). Also indexed "connect team" and "team synchronization" at this paragraph. Removed UTI 042 and 043. 06-318 ------ [249:13] Done. Removed UTI 044. 06-319r3 -------- [297:29] Done. Removed UTI 049. [311:32-33] Close but no cigar. The alluded-to problems (remote reallocation through the dummy) for an allocatable actual only apply if the dummy is allocatable. For a normal dummy, I see no problems whatsoever. Furthermore, this subclause does not apply to allocatable dummies! I've replaced this edit with what I believe to reflect the technical discussion in the paper, and modified UTI 050 accordingly. This is to ensure subgroup checking of my modification - no edit is necessary if you think I got it right! Modified UTI 050 accordingly. It seems to me that we need to apply these restrictions to allocatable and pointer dummy arguments, in which case an edit is required in the later subclause that deals with them. In fact, I went ahead and added such a requirement ... but this needs to be reviewed (if the requirement is stated elsewhere or is a consequence of other requirements, it is superfluous). Added UTI 096 about this case. [312:1-] Done. Removed UTI 051. [314:7-] Done, with "be associated with" -> "correspond to". And I omitted the inappropriate syntax rule reference; it is wrong because one can reference a procedure other than with the syntax that gets you R1223, but we still want the requirement to apply. Come to think of it, that is probably true of other constraints, sigh. Added UTI 097 about that (probably warrants an interp though). Removed UTI 055. 06-320 ------ [316:23] Done. Removed UTI 054. 06-321r2 -------- [14:12-14] "an object"->"a scalar object". [339:15] "The collective" -> "These", "optional argument TEAM"->"optional TEAM argument" Deleted index "synchronization!implicit team" because we don't have any other "synchronization!" items. The term "implicit team synchronization" doesn't contribute anything useful. It's just the normal word "implicit" plus team sync. It's defined once, referenced once (where the normal use of implicit works equally well) and indexed once (strangely enough, not at the only place it was used). Deleted the definition and changed the index entry to "team synchronization". Also, [347:10-11] Moved FORM_TEAM summary entry down 4 subclauses. [380:2] Done. [380:6-] Also indexed "team synchronization" here. Removed the cross-ref: there is no cross-ref for the uses in c09, and this is a defined term which shows up in the index (and the thrice-accursed annex A). Seriously, we should not be cross-referencing uses of defined terms, we should only do it when (for presumably good reason) we didn't use a defined term, or when none exists. Ok, so being consistent about that would mean a lot of changes, but it would be a lot of changes for the better, especially if we made uses of defined terms into hot links back to the definition. Also, [195:18] Added FORM_TEAM to the list of image control statements. Also, rewrote (simplified) the description of team synchronization as done by collective subroutines, and inserted a note about FORM_TEAM doing it too. (I didn't want to insert normative text, because that would have duplicated the specification in c13.) 06-322r4 -------- [252:8] Also, "the value"->"a value" immediately before. [430:1-2] Done. [436:9] "The type IMAGE_TEAM" -> "This type". [436:9+] Done. [437:21-23] Done. [440:23] Added a totally different sentence instead. The suggested edit was seriously defective, in that it did not affect subcomponents nor did it mention allocatable/pointer, which have substantial effects in a co-array environment vis-a-vis cross-image accessibility. Added UTI 098 about this. [474:2] Done. Incorporated this into UTI 098. Modified UTI 086: the paper did not address the issue of error vs. non-conformity. Removed UTI 087. The paper claimed it has an edit, in response to UTI 090, to make IMAGE_TEAM an extensible type. I saw no such edit. I made one. It further claimed that we did not need to specify whether it had pointer or allocatable components. I adamantly beg to differ. Modified UTI 090 accordingly. The paper claimed various rationales for special IMAGE_TEAM mollycoddling. They are mostly unnecessary/vacuous. In particular, the "in case of pointer components" ... well, the answer to that is not to special-case IMAGE_TEAM, just to say that it DOES IN FACT *have* pointer components. That means the special restrictions on IMAGE_TEAM can be deleted and we can use the pointer component restrictions instead. And because they are private, the user cannot validly touch them or do anything useful even if the implementation doesn't in fact use pointers at the hardware level. Modified UTI 073 accordingly. 06-323r1 -------- [494:24-25] Done. [495:11+] Done. Removed UTI 075. 06-325 ------ [359:35-37] Done. [359:37-38] Done. Removed UTI 061. 06-326r1 -------- [500:31] Done. [500:43+] Reworded. This has certainly improved the situation, but we are still in the "bits define too much" hole (the hole is a bit shallower though). Are we really trying to be lower-level or less portable than C? When you do this sort of thing in C, all bets are off. It is inherently a processor-defined situation; we should call it that. Modified UTI 076 accordingly. 06-327r1 -------- [495:10:11] Done. [298:1] Done. [298:1+] Done. Removed UTI 077. 06-329r1 -------- [199:15+] Done. [200:9-201:4] Moved the "Let Q..." sentence from the 1st para to the 2nd. Reworded the third paragraph. 06-331r4 -------- There were many problems with this one. Also, see the end of the comments for the disposition. Annex D is the syntax rule index. Indices come last. Therefore the new annex is Annex D leaving Annexes E and F to be the indices. Please don't try to tell anyone to add things to the table of contents. It *is* automatically generated. Actually, I don't think the Annex collects information, I think that Dan did; the Annex contains the information that was collected. I deleted a whole load of things that aren't processor dependencies, just "implementation guidance", "program guidance", ... in other words, witter. Things like "Portable programs should not ..." is not a dependency! If we are going to collect this junk I will insist that it be deleted from the main body of the text, and we can have a new annex called "Programming Guidelines". Over my dead body. Our standard way of representing italics in flat ASCII is not **italics**. Well, I'm just guessing that italics is what was intended here (the thing was a syntax term). Maybe the author ought to have used PDF so we could see it. The stuff about number of images is not supported by the normative text. Added some stuff to support it; since it's in "Exclusions", it no longer needs explicit listing in the annex -- so I deleted it. Added UTI 099 for review. The stuff about representation methods and kind type parameters is ungrammatical gobbledygook with nonsensical references. Turned it into UTI 100. Omitted the paragraph beginning "The precise details of the translations", since I have no clue what it is rabbitting on about. The word translation doesn't even appear in that subclause. Omitted the element-by-element ordering stuff. If it's undetectable by a standard-conforming program, it's not a processor dependency past the basic one of "we don't specify the physical properties of the computer". Many many other garbled entries untangled. A NEWUNIT= specifier does not set the variable to a processor-dependent value, it sets it to a *PROCESSOR DETERMINED* value. There is a significant difference. In this case, the numerical value is unpredictable but as a unit identifier the effects are completely specified by the standard; thus this is not a situation where it serves any useful purpose to call it "processor dependent". So I didn't (item omitted). The blank padding of input records is not processor dependent. (The note in c09 is a bit misleading here, I'll probably delete it.) The stuff about RECL= and nondefault characters is also junk (a technical term meaning, in this case, incredibly badly worded). I think it means that the EFFECT of RECL= is processor-dependent ("appropriate" is meaningless drivel). I'll probably fix that. The paragraph about ID= should probably use the same term ("processor determined") as NEWUNIT=, and again ought not to count as a processor dependency (through similar reasoning). Item omitted. Added the missing mention of POS= processor dependency. "Type mismatch" item was "junk" (see above). "The units used for derived type transfers" item was incorrect. This should probably be described as processor determined. Omitted the item. If we want to have a discussion about this, we can start from the premise that practically all values and operations produce results determined by the processor. It is not useful, for example, to list the results of RANDOM_NUMBER as being "processor dependent" though it might be useful to list the operation of RANDOM_SEED as being processor dependent. The statement in c09 about FLUSH (which this annex quotes) is contradicted by the very paragraph within which it appears. Added UTI 106 about this. "... returned by INQUIRE .... for the FILE= specifier ...": hilarious. IOLENGTH= isn't processor dependent. The number of file storage units required to store a value is. A processor is not permitted to produce 'NaN()'. "Unless the rounding mode is specified by ..." is completely adequately covered by the earlier text about ROUND=. Once the rounding mode is processor dependent, you don't have to go on about how it still is processor dependent (if you didn't change it) or no longer processor dependent (if you did change it). "When the rounding mode is processor dependent or nearest..." rubbish. That's PROCESSOR_DEFINED or NEAREST. No, processor dependent does not mean PROCESSOR_DEFINED, it means it is processor dependent *WHICH* of the rounding modes it is. (And if the rounding mode is PROCESSOR_DEFINED, all rounding is processor-dependent, not just the equidistant case.) The field width for B0, O0 and Z0 is processor-dependent, though it is not described using that term; added. Ditto G0. The T/TL/TR/X edit descriptors have a processor dependent effect when non-default characters are skipped in a non-Unicode file. Whether the optional plus sign appears is processor-dependent when the mode is PROCESSOR_DEFINED; added. The paper ludicrously omitted list-directed output, which is almost entirely processor-dependent and the one most users see every day! Added. Why did the author randomly lowercase attribute names? The target (sic) attribute stuff is entirely wrong. Not even close. "The means by which [a procedure defined by means other than Fortran] is defined are processor dependent". Sure, that's what the text in c12 says, but it's nonsense. Turned into UTI 107. "Specifically, whenever IEEE_VALUE ..." is a total non-sequitur. Omitted. Adding one missing item from c15. Didn't the author check this at all? The paragraph about ordering requirements is a NOTE. Notes are *Not Normative*. In any case, the note would appear to be either wrong, misleading, or simply gibberish. After fixing, this item should probably be deleted from the annex. Added UTI 108. PLEASE READ THIS: The approach taken by this paper is fundamentally mistaken. Inserting minute technical details and copying vast swathes of normative (and non-normative!) text is counter-productive and produces vast numbers of hostages to fortune. This approach means that any change to the text of the document will need to be double-checked in the annex -- this ain't gonna happen. It is not the approach taken by C99, after which this annex was allegedly modelled, and in this case the approach taken by C99 (basically a summary list with references) is superior. Therefore I have completely reformatted the results of the above along those lines, and changed the wording accordingly. 06-332r1 -------- This paper depended on a mythical version 06-311r1. The actual 06-311r1 (a) did not contain the definition of the term, (b) did not accurately reflect the results of the straw vote that was taken, and (c) did not pass in any case. [317:1-5] Done. Removed UTI 079. Added UTI 101 about the undefined term. 06-336r2 -------- [379:39] Done. [380:4+] Done. [380:5-] Done. [380:5+] Reworded. [380:6-] Done. [380:9] Done. [429:27] Done. Removed UTI 085. 06-337r1 -------- REJECTED - the editor cannot make sense of this paper. (The edits seem to have inconsistent technical effects.) It seems to be problematic in that (a) it takes a different approach to another paper passed by the meeting, viz 06-332r4. Unfortunately I did the edits for that paper first! The approach taken by 06-337r1 would probably have been preferable... (b) it results in contradiction in the standard; it contradicts 164:7 for a start, and I believe results in other contradictions in assignment etc. (c) the comments I made about 06-332r4 about the lack of necessity for special-casing IMAGE_TEAM apply with equal force here: if you want it to act like it has pointer components, just come right out and say it has them! (d) I am unconvinced that the technical direction of the paper is correct; I am distrubed by the inconsistency between disallowing all ptr=>tgt when cross-image, but allowing implicit cross-image ptr=>tgt. Since it appears that this issue could benefit from further technical discussion and appears to require substantial work on the edits, I have to reluctantly conclude that it would be better deferred until the next meeting. 06-339r2 -------- [50:27] Done. 06-340r1 -------- [54:28] Done. 06-343r2 -------- [34:26-27] Done. [34:37+] Done at 27+ instead (which is where it belongs). [End of clause 3] Done. 06-344r1 -------- [20:20] Done. [78:13+4-5] Second "values"->"type" instead (the C enum decl only declares one type). [117:13-14] Done. 06-345r2 -------- [86:17+5] Done. [89:9+4-5] Done. 06-346r1 -------- [117:11+] Done. [126:30] Reworded sentence. 06-347r1 -------- [145:13-146:4] Done. [165:11-1] Done. 06-348r2 -------- [186:3] Done. [186:7] Added "not" after "or shall" instead, since "and shall" does not appear on that line. [187:?] Done. [196:4] Done. [196:10] Done. 06-349r2 -------- [205:30] Done. [215:31-32] Done. [245:20+] Done. 06-350r4 -------- [301:1-] Added "PRINT *, " instead. [324:7+] Done. [334:35] Done. [296:25] Done. [314:9] Done. [316:19-20] Done. It would have been nice if the paper had actually noted the substantial technical change and said that it was correcting that error. Just bare edits does make one wonder whether the authors really intended what they wrote (anyone can make a mistake, so making one's intention clear is always a good thing to do). [320:3-4] Added "without the CONTIGUOUS attribute" instead. [321:9] Ditto. [336:8-9] Inserted "non-co-array" instead. [336:12-14] Done. 06-351r2 -------- [380:10-17] Done. [411:21-29] Done. [388:24+] Done. [430:26+] Done. [379:8-10] Reworded to avoid use of the term "array-element". 06-352r3 -------- [309:8+] REJECTED. This condition stated by this requirement cannot be met for procedure pointers, because the procedure pointer becomes undefined when the host exits. See "16.5.2.2.3 Events that cause the association status of pointers to become undefined" It is item (6) in the list. I will note that the events causing C_PTR to go undefined are defective in both F2003 and the current draft (could be fixed by an interp). Added UTI 102. [310:1-] Reworded first sentence to avoid imposing a requirement (even one whose preconditions cannot be me) in non-normative text. Reworded various other bits to make them grammatical (i.e. sentences). [326:21] I don't know where you got the reference 15.4.1 from. Binding labels for procedures is in 15.5.2. I hope this is right. Furthermore, after to your change to 15.5.2, it ALREADY specifies "no binding label" without any NAME= specifier. The approach taken by the paper doesn't really make sense; there are two possibilities - I picked one, which is to delete this constraint instead, letting internal procedures automatically have no binding label, and prohibiting them from specifying NAME=. Just like we do for dummies. Added UTI 103 for review. [481:10] Done. [503:11+] Reworded. 06-353r1 -------- [87:22] Done. [87:25] Done. [88:4] Done. 06-354 ------ Note: I put this on the wrong list, so did it here instead of as part of processing the /EDIT papers (07-101). [137:7+] Done. This results in what I consider to be a serious misfeature, highly error-prone to use in practice, in allowing comparisons between real and bits. Having "IF (x<1)" doing a totally different operation from "IF (x<1.)" is IMO extraordinarily poor design. This should be struck. People who ACTUALLY want to sort a mixture of REALs and BITs can do "IF (x