J3/98-110 Date: 28 Jan 1998 To: J3 From: Richard Maine Subject: Edits incorporated in 98-007 This paper describes the changes in J3/98-007 relative to the previous f2k draft, J3/97-007r1. All page/line references are to J3/97-007r1 unless otherwise noted. I have flagged several items as needing further attention in my opinion. For convenience in future citation, I have numbered these. They are all flagged with ***ACTION ITEM xx. Incorporates ISO editorial changes in f95, including a completely new forward, revised form of self reference in intro and 1.1, format changes in 1.9, formatting change on page 1, and 1-word changes on pages 7 and 13. Paper 97-236, more continuation lines, incorporated with no changes. Paper 97-249R1, min and max intrinsics, with the following changes. "i.e." -> "that is" several times. "is" -> "has the value" in examples several times. Paper 97-250r2, extend initialization expr, with the following changes ";" -> ",". (To be pedantically correct, there should be no punctuation there, but I agree that would read very poorly. I find the comma a reasonable compromise.) Paper 97-255, corrections to async edits, incorporated with no changes. paper 97-262, further async I/O edits, with the following changes [157:37] - fixed the list syntax for the 3 conditions. [150:31-36] Deleted the "that" in the first line to make the revised sentence parse right. I really don't like the change from "Any variable that" to "When a variable". The "when" phraseology implies that the attribute is time-dependent, which is not a concept that we have at all. I can buy that it is time-dependent whether a a variable is a pending I/O storage affector. But I don't buy any attributes (including ASYNCHRONOUS) being time-dependent. They are at most scoping unit dependent. Though I don't like this, I did leave it alone, as it was a J3-voted change to my previous wording. (I'm ok with the other changes). See below for more on this. In a note to me, the paper suggests that the term "base object" might be ok if it also covered the array element case. It does, so I used it. Furthermore, that term also covers the "object-name", so we don't need 2 separate cases at all, simplifying the sentence structure quite a bit. Remember that an object name is a degenerate form of a , and in that degenerate form, the object itself is the base object. The edit for "is implicitly" reduces to "the base object of the is implicitly". [58:36-37] Kept the section xref to 9.4.1.10. Simplified using "base object" as noted above. Instead of saying that the base object has to have the ASYNC attribute, I'd probably have preferred to say that the variable itself has to have the attribute. I'd then have said somewhere that if an object has the async attribute, then all of its subobjects have the attribute...or something like that. I think we'd end up with simpler wording all around, not having to refer to base objects of s all over. But I defer to JOR on the matter. Note 5.17. Also fixed my spelling of "coimpiler". (I've heard of "compliers" before, but I'm not sure how to interpret "coimpiler"). [59:3] Simplified using "base object". issue 2 (on section 5.1.2.12) ***ACTION ITEM 1 Well, ok. Perhaps it is just that the wording in the first para of 5.1.2.12 is a bit confusing. I think perhaps it mixes static and time-dependent concepts, and I think parts of it are redundant. If you are keying off the fact that the variable is only an affector while a data transfer statement that references its storage units is pending, then it is redundant to also have the condition that a data transfer statement be pending - if the variable is currently an effector, then one must be. I think the biggest thing here is to more clearly delineate static from time-dependent conditions. I'll think about wording... (later) Hmm... How about something like "The base object of variable shall have the <> in a scoping unit if (1) the variable appears in an executable statement or specification expression in that scoping unit and ["in an expression or executable statement"? your choice] (2) any statement of the scoping unit is executed while the variable is a pending I/O storage sequence effector (9.4.1.10)" The biggest point of this wording is that the pending I/O storage sequence effector stuff is mentioned in a time context (with "while"), but the static characteristics are outside of any time-dependent conditional phrases. Since there have been a few revisions in this wording already, I have *NOT* made this change just on my own, but I commend it to J3's (and JOR's) attention for the next revision. ***END ACTION ITEM 1 Deleted the J3 note from 9.4.1.10. The question seems adequately addressed. Issue 4 (scoping and inheritance of async attribute). JOR asked for some guidance on what I thought was needed here. I think most of the questions here are now adequately addressed; the information is there, if one digs enough and looks in all the right obscure places. Perhaps the only thing remaining is a clarification, perhaps in a note somewhere. I haven't written the words or determined the best place (and I'm rushing to get things done, so I don't think I'll try right now). But I think the point that needs to be clarified is that the ASYNC attribute of a variable can be different in different scoping units. Yes, the info is there, but it is *AWFULLY* hidden. The critical words to find are: In section 11.3.2, right before note 11.8, it says that you can give the async attribute to something USE'd from a module. This is at least pretty explicit, but I'm betting that a lot of people will never think of looking here to find something about the async attribute. There are no xrefs to this anywhere. The really tricky one is in section 14.6.1.3. I should leave this as an exercise and see how many people find it! I challange all to try it now before reading further. The word "asynchronous" doesn't appear anywhere in this section (and indeed, only once in all of section 14, that being on the last page). But "the dog did nothing in the night" and that was the clue. It is the absense of any mention of asynchronous in 14.6.1.3 that is the critical information. Appearance of a name in an ASYNCHRONOUS statement for a host-associated name is not listed as one of the things that "hides" the host-associated name, therefore such an appearance gives the asynchronous attribute to the host associated name in the local scope (unless some other statement creates a local variable that "hides" the host associated name, in which case the asynchronous statement applies to the local variable) I don't want to have to write that line of reasoning into an interpretation answer (though I think it is valid). So lets forestall it by making the conclusion a little more explicit. ***ACTION ITEM 2 A note somewhere should point out that the async attribute for a variable accessed by host or use association can be different from that of the original variable. This is unlike most other attributes except for private/public. It should xref section 11.3.2 and point out that you can give the async attribute to something accessed by use association (but that you can't take away the async attribute if the original had it). And it should xref section 14.6.1.3 to note that an asynchronous statement can give the async attribute to a host associated variable without "hiding" it. Again, we might further note that the inner scope can only add the async attribute, not remove it. I'm not sure whether we need to say anything special about common and argument association. Since I didn't come up with the words, I've left the J3 note about in 5.2.10, though I changed its words to say that we need to clarify this, instead of needing to specify it. ***END ACTION ITEM 2 [153:36+] Omitted the "identified in (2)" phrase. It is adequately implied by the "the unit". The other portions of this list use similar implications, and even some one level more indirect. For example, they refer to "the file" instead of "the file connected to the unit identified in (2)." Fixed the list syntax for the 3 conditions. Added periods after all the items in the numbered list. (It probably needed them before, but it really stood out once some of the items were multiple sentences and thus had periods, while other items didn't/) Factored "condition" out of the list in old item 6 (new 7), just like we do elsewhere. (Not really related to paper 97-262, except that it used the same list several places, which brought it to my attention). Kept this change in the "copy" of this item made for the async case. ***ACTION ITEM 3 I don't really think you want to say in the new 9.4.4(3) that "execution of the current data transfer statement is terminated." Setting the value of the IOSTAT variable is specifically identified by the last item in this list as part of the execution of a data transfer statement. I don't think you want that skipped. (Hmm, now that I think of such things, why isn't there a subsequent item for possible transfer of control to statements identified by end=, err=, or eor= specifiers? That also seems like part of the execution of the statement to me). You probably just want to say that steps 4-8 are skipped. Hmm. Still thinking of such things, it seems like the description of error handling is all messed up here. We only consider errors in one place (the old item 6, new 7)? What if an error occurs in the next step (position file after data transfer)? We ignore that? Or what if one occurs much earlier - say in identifying the unit? We still do file positioning and data transfer even when we don't have a unit? (I suppose you could conceptually say that we still do all these things, but that they all fail because of the error condition). I'm going to leave this for the J3 or JOR to work on because there can well be real semantic content to some of these questions (example - questions of whether variables in the i/o list become undefined if we have skipped the step of transferring the data as opposed to having an error in it). Plus, I'm short of time, so any excuse for avoiding more work on it right now will do. So I've entered it as requested for now, even though I think it needs work. ***END ACTION ITEM 3 [154:1+] item (5) "may" -> "might" ", if the variable read" -> "if an input variable" Multiple problems with the original here. The comma didn't belong. The definite article (the) was inappropriate. And it was correct, but just too confusing to use the term "read" here because you needed to parse the rest of the sentence before determining whether "read" as pronounced "red" or "reed" was intended. "implied-do-loop" -> "implied-DO" [154:1+] item (6) "trigger" -> "possibly trigger" (otherwise we seem to imply that completion necessarily triggers errors). Deleted a comma. [154:1+] item (7) Factored out the "may occur". Deleted several commas. "which" -> "that" "an already pending asynchronous I/O operation" -> "a previously pending data transfer operation" This is mostly to use the same terminology as used elsewhere. Also, it is redundant to say "pending asynchronous" (we can't very well have pending synchronous operations), and it is only the data transfer operation that can be pending, rather than some other kind of I/O operation (file positioning, etc.) "whose initiating data transfer statement did not contain an ID= specifier" -> "that does not have an identifier". (Recall my strong bias towards separating syntax and semantic concepts. The important thing here is the semantic concept of whether the data transfer has an identifier - not the syntax that was used to make it have one). If the term "identifier" seems to vague, we can make it something more specific like "data transfer identifier", in which case we'd want to also use that term in 9.4.1.11). Also, the resulting sentence simplifiction makes it legible without the grammatically incorrect commas. We could adopt a term like "anonymous" to describe data transfer operations that don't have identifiers if people like the idea. But I don't think it is probably used enough to need that (though it would simplify sentences like this further changing the clause "that does not have an identifier" into the single word "anonymous".) [154:1+] item (9) Used "any" instead of "the". The "the" implies that such a variable must exist. Deleted the comma. ***ACTION ITEM 4 Section 5.1.2.12 uses the term "pending I/O storage sequence affector" and xrefs 9.4.1.10 for it. That term is not yet defined anywhere (in fact, a grep fails to find the word "affector" anywhere else in the document). This is noted as "edits not available yet" for issue 10 in paper 97-262. I'm just adding this here as a reminder, so it doesn't get forgotten. Hey, I know. I'll add a J3 note in 9.4.1.10. Done. ***END ACTION ITEM 4 [158:26+] "opened for synchronous " -> "not opened for asynchronous" Though I usually prefer positive forms, I think we need the negative one here. There question is whether asynchronous I/O is allowed; this is not the inverse of whether synchronous is allowed. One might consider a file opened with ASYNCHRONOUS="yes" to be opened for both synchronous and asynchronous I/O. And I changed the "without an ID= specifier" to "provided that the WAIT statement has no ID= specifier" (placed later in the sentence) because otherwise I found it confusing to read "...without an ID= specifier specifying a unit that does not exist..." (the "specifying was meant to modify the "statement" from earlier in the sentence, but it was sure easy to misread). As Henry noted, also added the WAIT statement in 9.3.1 and 9.3.2 to the list of I/O statements that may refer to units that are closed or non-existant. For the sentence in 9.3.2, fixed its strange list syntax and made the sentence consistently singular by using "every" instead of "all" (it was a mix of singular and plural). [297:32] I'm still dubious of JOR's argument here. It seems that we are leaving it undefined which variables are undefined...and we are saying that the user better know which ones are really undefined because the standard doesn't say. JOR's suggestion that "if the user doesn't know...he better not use any of them" sounds like saying that they are all undefined to me. Remember that, in the Fortran sense, "undefined" doesn't mean that the variable might not happen to have a value. It just means that you "better not try to use it" (so you can't legally tell what value, if any, it might have). On the other hand, we both agree that my cop-out wording was bad. I'll go ahead and put JOR's basic wording here.... Except that I see Henry has a good editorial comment, which I used, on how to make the double negative (almost triple with "except" and 2 "not"s) into a positive. Then also "which"->"that", delete commas, make singular, and avoid the confusing juxtaposition of two "that" clauses modifying different things. Ended up changing the words quite a bit, but these changes are all editorial and unrelated to the technical question mentioned above. Deleted both J3 notes from C.6.3. They seem adequately addressed. [154:12] "an" -> "a", and "I/O" -> "data transfer". (We try to consistently use the term pending data transfer operation; no need to use a second term for the same thing). [154:14+] "Since" -> "Because" (No time relation is implied). "which did not contain an ID=" -> "without an ID= specifier" (Better without time reference here - and "which" is wrong anyway). Added "for the unit". (Read statements for other units would not be pertinent). [158:36+] "will perform" -> "performs". (We've generally used present tense for such constructs). [158:39] "statment" -" "statement" ***ACTION ITEM 5 [158:39] "synchronous" -> "asynchronous". I've flagged this for action because I'm hesitant about whether I got it right. As I see, synchronous data transfer statements actually perform wait operations for all pending stuff on the unit, so it wouldn't make sense to say during the wait operation or during a subsequent synchronous data transfer statement. I think its the asynchronous ones that you meant to cover here. But I'm not at all confident. ***END ACTION ITEM 5 Henry suggested changing ID to ID= in the title of section 9.4.1.11. I can see arguments both ways, so I left it alone for now. We seem to have several cases of headings both ways. The text does tend to use the form with "=", which is an argument in that direction. On the other hand, I don't particularly like punctuation characters in titles. I'm not adamant either way, but since this isn't the only case that's this way, I just ignored the question for the moment. paper N1282, the allocatable components TR. This appears to be the latest version of this TR. I was initially somewhat confused by N1308. I went to make the changes indicated by N1308 and discovered that they were already in N1282, and in fact, in N1275 from April 97 (about 8 months prior to N1308). N1308 appears to be comments on N1230 from Oct 96. Did the following 2 edits from my comments on the DTR. (Malcolm agreed with these and, in fact, initiated one of them). 5.1, R501-506, 3rd constraint [48:1-2] Delete: "that is not a dummy argument or a function result" 6.3.3.1, new paragraph at end of section [83:18+] "When a variable of derived type is deallocated, any ultimate component that is a currently allocated allocatable array is deallocated (as if by a DEALLOCATE statement." I think it better to talk about derived types "having" components instead of "containing" them. So "contains" -> "has" 2 times "containing" -> "that has" 3 times (and 1 extra case in 5.5.1) "containing" -> "with" 1 time "that contains" -> "with" 1 time "contains a reference to" -> "references" 1 time. ***ACTION ITEM 6 [37:42], [38:2] The glossary entries haven't been updated to correspond to these. It has been suggested that the term "direct component" might now be superfluous, largely replaced by subobject. It only appears to be used in c14. I haven't done anything on these. At least the glossary fix should be done. Added a J3 note in 4.4. ***END ACTION ITEM 6 [48:12] Changed the constraint to singular, while I was there. This is really independent of the TR and is just editorial. [69:1] Reorder words to be identical to those used twice in 5.1. [80:29+] "If" -> "When". Time is at issue here. Its not just "if" an object is created by an ALLOCATE statement, this happens "when" the object is created. The allocation status may well change later. Also "ultimate allocatable" -> "allocatable ultimate". ***ACTION ITEM 7 The TR needs to be integrated with the f2k definition of "subobject." I've taken a stab at how to do this. Its not quite done. In particular, I haven't written the standardese in section 6.1.2 to define this. I did put a J3 note there somewhat sloppily explaining my concept of it. Some of the other edits here assume that concept is adopted. Otherwise all the uses of "subobject" in conjunction with allocatable components will need to be revisted. Malcolm and I have talked a bit about this. He has some other approaches that might work better, including an intriguing idea of treating allocatable components more like zero-sized arrays than like disassociated pointers. The whole question needs more work. ***END ACTION ITEM 7 [80:42+] "an ultimate component" -> "a subobject" This needs my proposed definition of subobject. As Malcolm noted, the sentence is probably superfluous anyway, but if it stays, this change is needed to fix the interaction with pointers and to cover multiple "levels" of allocatable components (since "ultimate" stops at the first level). Deleting the sentence is also an alternative. [80:43] "an ultimate component" -> "a subobject" Otherwise it needs "non-pointer" to catch the interaction with pointers. Malcolm argued that the "non-pointer" wording fixed this better, and I'm not sure whether we've yet agreed on that point or not. [83:10-13] This list uses comma separator instead of periods. "an ultimate component" -> "a subobject" (twice) for consistency with [81:1] and because this needs the subobject semantics instead of ultimate component semantics. ***ACTION ITEM 8 There are still some inconsistencies between sections 6.3.1.2 and 6.3.3.1. For example, 6.3.1.2 fails to include the exception for dummy arguments. I wonder why all this needs to be said twice anyway. I added a J3 note in 6.3.1.2. ***END ACTION ITEM 8 [83:18+] Changed from "ultimate component" to "subobject" terminology. Simillar issues to [80:43] in that it needs at least a fixup to say non-pointer if we use the "ultimate component" terminology. ***ACTION ITEM 9 [149:6] It isn't clear to me that there is any real problem with allocatable components in output list items. This isn't like the case of pointers where the pointer inherently looses its semantics when written to a file. For formatted input I can see that there would be ambiguities, but I see no problem in formatted output or in unformatted i/o. This is clearly more than an editorial matter. There is also obviously nothing wrong with disallowing it. I just commend it to J3's attention as a possible extension as part of the f2k integration. ***END ACTION ITEM 9 [203:22], [205:5] Used subobject terminology here instead of ultimate component. Otherwise there are several problems. Also changed "part" to "subobject" a few lines after the first of these edits. [293:12-13] Italicized "named" (which should have been done in f95). ***ACTION ITEM 10 As a possible f2k integration enhancement, I suggest we consider allowing initialization of an object of a derived type that has a component that is an allocatable array? At least allow it to be initialized to null()? This one may have subtleties that I don't yet appreciate. It seems odd that we can initialize something with a pointer component, but not something with an allocatable component. Ok, so its redundant because it is implicit anyway. Why not allow it to be explicit? Are there reasons other than the apparent redundancy for disallowing it? The restriction as currently stated disallow things that are not redundant, like initialization of objects of derived type that happen to have an allocatable component. This is clearly not an editorial issue. I commend it to J3's attention as a possible enhancement to add during integration. Related issues include allowing ALLOCATABLE components in parameters. ***END ACTION ITEM 10 ***ACTION ITEM 11 This isn't directly related to the TR, but came up while I was studying the DTR (and wondering why we couldn't allow PARAMETERS with the allocatable attribute as mentioned above). I suggest we consider allowing pointers with the parameter attribute. Yes, the only possible value is NULL(), but that happens to be useful. For example, you might want to pass it as an actual arg for an intent(in) dummy pointer. Note that we do allow parameters with pointer components (note 5.8 even has an explicit example in case anyone has any question), so lets allow the simpler case also. I might argue that this is appropriate as an integration issue for intent for pointer dummy args. A pointer parameter is much like an intent(in) argument. ***END ACTION ITEM 11 paper N1281, the floatting point exceptions TR. This appears to be the latest version of this TR. This appears to already incorporate the changes listed in N1307. I did a pretty hasty job on putting this in. Its fairly big and I need to get the next draft out pretty soon. I concentrated mostly on the mechanics of getting it in; didn't really have the time to study it word-by-word, as I have some of the other stuff. Simillarly, some of the formatting details are a little sloppy, perhaps to be improved later (things like consistency in where blanks are used and what style of blanks they are). I note that there are no index or glossary entries for anything in the new exceptions TR material. There probably should be some. I didn't have the time to do anything about it. I added the IEEE standard to the normative references. The DTR lists it as a normative reference (so I stole the exact citation from there, complete with the note about referring to it as "the IEEE standard"), but the DTR didn't include it in the edits. It "obviously" is needed. In 15.0, changed the 2 refs to 15.9 to refer to the specific 15.9 subsection and put the xrefs in parens following our usual style. A colon to "as is" before the first USE example. Globally changed all "must" to "shall", except for the 2 occurances of "caller must" in 15.10; changed those to "caller needs to". (Those two are requirements of the programmer, not the compiler). Globally changed all cases of "may be determined/changed/used/saved" to use "can". Changed all uses of "May involve/be slowed/be expensive" to use "might". Left other uses of "may" (in "may signal/provide/occur/cause/lead/be influenced/be scalar") unchanged. In 15.1, refer to the modules as "defining" instead of "containing" derived types and parameters. The section title already used "defining". The term "containing" is potentially confusing because the derived types are not in the "contains" part of the module. 15.1 "modules" -> "module" twice in the description of IEEE_FLAG_TYPE. Presumably typos. And "module" -> "modules" in the 15.1 section title. One "contains" -> "has" in 15.2. Deleted colons as appropriate from a few of the bullet lists. Converted the "notes" in several places to informative shaded notes. It was not entirely clear to me whether this was intended or not. The DTR doesn't mention anything about informative notes, so one could argue that it is normative. On the other hand, the material does seem a likely candidate for an informative note, and we have no existing editorial construct otherwise simillar to the indented notes; I'm not sure whether the indentation difference (some are indented and some are not) was intended to convey some real difference or not. ***ACTION ITEM 12 I don't like the usage of the terminology "execution of a process" in the paragraphs after the new note 15.1. It seems vague (what process?) and we don't have any technical definition for what "a process" means anyway. But I didn't do anything about it. In the same area, I also question the terminology "a process further to those required or permitted by the standard." Among other things, it sounds almost circular - doesn't it essentially say that if the standard prohibits something, then that something shall not happen? Maybe the interval folk could look at this. Sounds very simillar to some of the questions they raised about when optimization is legal, and how to specify such things. ***END ACTION ITEM 12 Lower-cased "rem" in 15.7 to be like the other names in the same list. I don't know whether there was supposed to be some reason for the distinction. In 15.8.1, made the line "The module IEEE_ARITHMETIC..." a regular paragraph instead of a bullt. I presume this is a typo. Singular "Argument" in 15.9.6. In 15.9.17, "a IEEE" -> "an IEEE" twice. In 15.9.18. Delete colon and use "or" instead of "and" in the list of valid values for FLAG. I might have passed over one or two other simillar cases elsewhere. In the note in 15.9.22, IEEE_SUPPORT_DATATYPE -> IEEE_SUPPORT_DENORMAL. I presume this was a typo. In 15.9.24 and 15.9.25, "and"->"or" in the list of valid values. A few cases of "Examples" -> "Example" when there was only one. ***ACTION ITEM 13 Shouldn't 15.9.25 be more specific in that it should inquire whether halting can be controlled by IEEE_SET_HALTING_MODE, rather than just whether there is some unspecified means of controlling it (like a vendor-specific intrinsic, some of which *DO* currently exist, so this is not just academic)? Also, shouldn't IEEE_SET_HALTING_MODE have some reference to whether this capability is supported or not? What happens if you call IEEE_SET_HALTING_MODE when setting the halting mode isn't defined? Perhaps the INTRINSIC doesn't exist in such a case; perhaps it does nothing; perhaps it sets some exception? I don't see any mention of this obvious error condition. Well, I guess it does say undet IEEE_SET_HALTING_MODE that "the processor must/shall either already be treating this exception this way or be capable of changing the mode so that it does." I suppose that means it is just illegal code to call it if you don't know that the processor can do it. But how do you know that? Presumably from IEEE_SUPPORT_HALTING, but I don't see the connection made explicit. Probably simillar questions for what happens when you call other "unsupported" things. I haven't taken the time to make a full list. ***END ACTION ITEM 13 15.9.27 "of"->"or" in result. All of 15.10 put into shaded notes. misc edits [53:13] "An nonpointer" -> "A nonpointer" [85:15] add "allocated" before "allocatable" As pointed out by John Reid. You want unallocated allocatables to stay unallocated, not be processor-dependent. It seems inconcievable that the processor might want to spontaneously allocate them to some arbitrary size. It is only when they were previously allocated that you want to give the processor the liberty to leave them that way or to deallocate. [355:4] "The this" -> "In this" in first 2 words of the index. A typo in f90 pointed out by Miles. ***ACTION ITEM 14 While perusing other things, I noticed that 14.7.5(6) is wrong for INTENT(OUT) arguments. I didn't take the time to fix it or to check for simillar problems elsewhere. ***END ACTION ITEM 14 ***ACTION ITEM 15 Section 12.4.1.5 seems to miss several restrictions on pointer optional dummy arguments that are not present. For example, they should not be allocated, deallocated, pointer dereferenced (which might not always constitute a reference), pointer assigned, or nullified. There might also be simillar omissions for allocatable optional dummies. ***END ACTION ITEM 15