J3/00-102 Date: 14 Jan 2000 To: J3 From: R. Maine Subject: Changes to list of unresolved issues The following are changes made to the list of unresolved issues. These changes are reflected in 00-011 and in the J3 notes of 00-007. These changes add 26 new issues and resolve 80. This makes a total of 237 issues, 167 of which have been resolved, and 70 of which remain. I. Resolved issues paper 99-179 resolved 11, 12, 22, 27, 173, 175, 176 paper 99-185r4 resolved 78. paper 99-187r1 resolved 134. paper 99-188r1 resolved 138 and 140. paper 99-203r2 resolved 178-190, and 192-200. paper 99-205r2 resolved 147 and 155. paper 99-222r2 resolved 24. paper 99-224 resolved 59. paper 99-234r2 resolved 21 and 62. paper 99-235 resolved 201. paper 99-237r2 resolved 26. paper 99-238 resolved 210. paper 99-243 resolved 121. paper 99-244r1 resolved 142. paper 99-245 resolved 202. paper 99-247r3 resolved 20. paper 99-248r1 resolved 125. paper 99-249r1 resolved 67. paper 99-258r1 resolved 118. paper 99-259r1 resolved 32, 33, and 129. paper 99-260 resolved 100, 102, and 174 paper 99-261r1 resolved 34. paper 99-262r2 resolved 86 and 203. paper 99-264 resolved 137. paper 99-265 resolved 205, 206, and 207. paper 99-267 resolved 135 and 136. paper 99-270r1 resolved 97, 101, 163, 165, 166, 167, and 170. paper 99-271r1 resolved 150, 152, 153, 154, 156, and 158 paper 99-273 resolved 220 (which was added by an earlier paper in this same batch) paper 99-274r1 resolved 87 and 88. III. Changed unresolved issues paper 99-179 modified issue 26 to say "Paper 99-179 added IEEE_SUPPORT_IO to the table in 15.8.1. Should it not also be mentioned somewhere in the text such as 15.3? I think all the other IEEE procedures are mentioned somewhere in the early text of the section." paper 99-185r4 modified issue 141 to say What about type parameters in other cases where deferred type parameters are not currently defined? Paper 99-185r4 partly addressed this question, but it appears incomplete. It mentions only the case where target is a disassociated pointer. Three paras earlier, we felt it necessary to separately mention the cases where target is a pointer with undefined association status and where it was a reference to the NULL function. Why did we have to distinguish those there and not here? Perhaps the NULL function case is ok - I'm not quite sure why we distinguished that before (doesn't seem to me particularly different from some other function that returns a dissasociated pointer). But a pointer with undefined association status is certainly different from a disasociated pointer. Also the former version of issue 141 mentioned the case where a null (should have said disassociated, I guess) pointer is an actual argument for a pointer dummy. I see no edits or comments about that case. Can I assume this means that it was looked at and determined not to be a problem? Or was this issue closed without actually checking that all the questions it raised were addressed? Also, I find myself greatly confused by the revision that paper 99-185r1 made to the above para. In addressing the issue of undefined type parameter values, it appears to have changed the conditions on cases where the type parameters are well defined. And I don't understand the change. The former version of this para said that *ALL* nondeferred type parameters of pointer-object had to agree with the corresponding type parameters of target. The new version appears to allow disagreement as long as the type parameter of target is deferred. This doesn't make sense to me. (And this isn't a constraint, so its not just a matter of checkability). There were words explicitly added to single out that case, so its presumably not just a matter of forgetting about the case. paper 99-186r1 modified issue 79 to say Paper 99-186r1 addressed the issue of assumed and deferred dummy type parameters, but it doesn't look complete to me. What about all the other cases of deferred type parameters (when the dummy is not allocatable or when the associated actual is not allocated)? Suppose the dummy is a pointer? Or suppose the actual is not allocated/associated? Part of this issue overlaps issue 141, which was also only partly addressed. paper 99-205r2 modified issue 156 as specified in the paper paper 99-219r1 modified issue 14 to say In 12.4.1.6, how about cases like ASSOCIATED(X%P), where P is a pointer component of an optional argument X that is not present? I don't see that covered anywhere. Its not a reference. Its not supplying X as an actual argument (just a component of X). paper 99-179 modified issue 158 as described in the paper. paper 99-222r2 revised issue 64 to read The technical issues of the original issue 64 appear to be adequately addressed (with 2 alternatives, even), but the differences in the editorial treatment of ROUND= and DECIMAL= in 9.5.1 are confusing. These two specifiers seem very similar in that they appear in both OPEN and in io-control-spec-list, with the one in OPEN applying only if there is none in the io-control-spec-list. Why then are they described so differently in 9.5.1? DECIMAL= has a subsection in 9.5.1, but ROUND= has none, just referring back to the OPEN statement. Either mode seems ok, but I don't know why these two are inconsistent. Later...I see that paper 99-242 (which didn't pass) has words that could address this; perhaps that part of 99-242 can be used to fix this. paper 99-236 revised issue 13 to read 14.8.5(6) is now ok as far as it goes, but the default initialization stuff for INTENT(OUT) is not handled. I have a note that Malcolm was going to write an interp on that. Pending such an interp, this is a placeholder to note that something is needed. paper 99-238r1 revised issue 208 with the text from the paper (rather than deleting that issue and adding a new one on a similar matter. Also added the following para: Except that all the discussion about what's new in F2k doesn't belong mixed in the explanation of the organization at all, so it may get added here as a temporary measure, but it better end up getting moved. paper 99-241r2 revised issue 3 to say Paper 99-241r2 made improvements, but there are still inconsistencies between sections 9.5.4 and 9.9. Section 9.9 says that execution of an input/output statement terminates when an error, end-of-file, or-end-of record condition occurs. It then describes several things that are supposed to happen after execution of the statement terminates. This strikes me as somewhat of a contradition in terms. These things are part of the execution of the statement; it says so in item 10 of both lists in 9.5.4. This description also explicitly contradicts the part of 9.5.4 that shows determination of the error status as step 7, with several subsequent steps that are not skipped in the case of errors. paper 99-261r1 modified issue 83 as described in the paper. paper 99-271r1 modified issue 151 as described in the paper. III. New unresolved issues paper 99-179, IEEE issue 212 - infinites and NaNs I inserted note 15.15 in section 15.8.2 as specified by paper 99-179, but its placement puzzles me. It comes after the description of IEEE_VALUE, which it doesn't appear to have much relevance to. Perhaps it is intended to cover all of the procedures in 15.8.2, but this is not clear. I also question whether 15.8 is a proper place for specifications like this at all. The section says it is just a tabulation, and I find no other specifications in it. I am also puzzled by this material being in a note. Is this supposed to be a consequence of specifications elsewhere? issue 213 - IEEE_SET_ROUNDING_MODE I did the edit to IEEE_SET_ROUNDING_MODE as specified by 99-179. However, I note that this edit changed the technical meaning in a way that I am not sure was intended. The restriction now says "for some X", whereas the previous version said "for any X". The meaning is very different. I also suggest wording that uses a phrase like "with a ROUND_VALUE such that"; see, for example IEEE_SET_HALTING_MODE. Also, another edit in the same paper added a restriction on IEEE_SUPPORT_ROUNDING that makes it redundant to mention IEEE_SUPPORT_DATATYPE here if we stay with "some", although it is still appropriate with "any". paper 99-203 resurected issue 7. paper 99-205r2 issue 218 - C variable interop definitions The paper's J3 note on this in 16.2.7 is numbered 218. I also added the following para: And while on the subject, will need to straighten out the useage of "shall" vs "may" in this regard. The editor can't do this because he isn't clear about the intended meaning (and suspects that he isn't the only one). issue 219 - Association with C variables The paper's J3 note on this in 16.2.7.1 is numbered 219. paper 99-209 issue 214 - value without bind(c) The note specified in paper 99-209 is assigned number 214. Also added the following para to it. "The editor notes, however, that INTENT(IN) dummies cannot currently be redefined and that allowing it in special cases would likely require changes in multiple places in the standard - and in his concept of what INTENT(IN) means. I certainly don't understand the above "thus"; it sounds to me more like the subsequent clause contradicts the preceding one instead of follows from it." paper 99-186r1 issue 215 - polymorphic argument agreement Replaced an earlier version of this issue because paper 99-254r2 seems to have fixed the problems I had with paper 99-186r1. But... The editor got a bit confused in entering the edits for the first few paras of 12.4.1.2. Papers 99-186r1 and 99-254r2 both had edits in this area. The later paper said that it replaced the earlier edits, but I got slightly confused about exactly how much was replaced. For example, I construed the replacement to include deleting the note added by 99-186r1. If that note is resurected, I had several problems with it. These included its use of the term "run-time" and its apparent assumption that restrictions that were not constraints would be checked at compile time. A sentence about the dummy argument assuming its type from the actual seems to have disappeared somewhere. I'm not sure now whether some other paper said to delete it or whether I just did so by accident. Too many papers for me to check now. Someone else needs to look over this. It may be all fine, but it needs independent checking. paper 99-196r2, with issue 216 - associate-volatile interactions The paper's J3 note on this is numbered 216. paper 99-211r1, c_float issue 217 - c_float The editor thinks all the special negative values for C_FLOAT et. al. added by paper 99-211r1 are silly, overly complicated, and irrelevant. C_FLOAT isn't asking about precision and range. It is asking about interoperability with C. I don't see what precision and range even have to do with it. But just because the editor thinks it silly doesn't make it wrong. Feel free to delete this issue if, on reflection, you find the editor's objection sillier than what he is objecting to. paper 99-222r2, responses to wg5 issue 220 - round to nearest The paper's J3 note on this is numbered 220. Added also a second para: The editor questions tbe assumptions in the above para about "average consumer expectations", but he appears to be in a small minority, at least in J3. ...later. This issue is resolved by a later paper (99-273) in this same batch, but it already got a number. So the number stays assigned, but the issue never actually made it to a released version of the 007 document. paper 99-238, intro stuff issue 221 - host association intro The paper's J3 note on this is numbered 221. paper 99-247r3, pointer stuff issue 222 - pointer targets The preceding sentence (It may be specified..." does not parse the way that I suspect it was intended. I suspect it was intended to be a list of 3 ways, but it doesn't parse that way. The last phrase (beginning with "or") doesn't make sense as an object of "specified" (or it would read "specified be the result..."). Thus I parse the sentence as giving two ways, with "by a pointer" as an appositive description of what it means to be specified directly. I didn't bother to try to rewrite it, partly because I was also uncertain of the following extra question. I'm not sure what the phrase "target of a pointer assignment" is supposed to mean anyway. We have the target of a pointer - that's one thing. And we also have the in a pointer assignment statement, which is another. The description above sounds like a mixture of the two. The of a pointer assignment statement is a bnf term and should be italic. But it also doesn't need to be a data object or procedure. (It could be a null pointer, which I don't think is either - though I could be wrong on that). The target of a pointer can be specified in many ways other than a pointer assignment statement. I find the para more confusing than helpful, but perhaps it's just me. paper 99-254r2, unlimitted polymorphic issue 223 - polymorphic objects Seems to me that section 5.1.1.8 on polymorphic objects could use some cleanup and re-ordering. The 1st sentence of the 2nd para appears to ignore the unlimitted polymorphic case. The 3rd para starts talking about being associated with objects "out of the blue." Its the first time the word "associated" appears in the section, but it sounds like it is meaning to refer to material above. The definition of "dynamic type" seems a bit late, being several paras after we started discussing the concept. And it looks like we repeat ourselves in talking about the concepts of what types an object may assume, what types a type is type-compatable with, and what types an object may be associated with. issue 224 - type compatibility in pointer assignment. Doesn't the above constraint (requiring type compatibility) make the one before it (special case for non-polymorphic) redundant? paper 99-260, C glossary entries issue 225 - italics in glossary Paper 99-260 is only the latest of many papers to ignore the above-described convention about use of italics in the glossary. The editor is too rushed to attempt to fix it this time, and it wouldn't be surprising if he had forgotten it or missed some cases other times. If we retain this convention, the whole glossary should be reviewed to do it consistently. I would propose that we instead drop the convention. I find it more obtrusive and garish than helpful (seems like half of the words are italic). Evidence suggests that there are others on J3 who also don't find it useful - I don't know any other explanation for the regularity with which it is neglected. (Those who might suggest that it is intentionally left to the editor to handle are advised not to make such suggestions in the editor's presense). paper 99-262r1, BIND(C) issue 226 - BIND(C) The paper's J3 note on this is numbered 226 Also added the xtra sentence. If it is fixed, might as well fix its 2nd "shall" also; it would be better as something more like "has to", "needs to", or "is required to". paper 99-270r1, interop issue 227 - enum interop The above sentence (in 4.7) still talks about objects interoperating with types and wasn't fixed by 99-270r1. The sentence is also pretty convoluted to the extent that I'm not sure it makes sense. What does it mean to talk about a type that the processor uses to represent a type? issue 228 - bind or bind(c) attribute? I'm confused about when we refer to the BIND attribute versus the BIND(C) attribute. I can't detect a pattern. Section 5.1.2.15 defines the BIND attribute, but we seem to refer to it more often as BIND(C) than just bind (see an example in 5.1.2.14; there are others elsewhere). issue 229 - xref for binding label Paper 99-270r1 deleted the section that was cross-referenced above. I'm not sure whether to substitute some other section or to just delete the xref. The scope of binding labels is now discussed in 14.1.1, which might be a possibility, but I'll let interop make the decision. paper 99-271r1, bind-specs issue 230 - constraint on procedure-declaration-stmt Two problems with the last constraint in 12.3.2.3. First, there is no such bnf term as language-bind-spec. I suspect language-binding-spec was meant, but bind-spec also seems possible (given my general confusion here). Note it appears twice. Second, it fails to deal with the optionality of proc-interface. It is not explicit whether proc-interface is required to appear and to meet these conditions, or whether these are conditions that must be met if proc-interface appears. I am guessing the former, but it isn't explict and could be read either way. issue 231 - example of BIND= The role of the first USE ISO_C_BINDING in the above example (in 12.5.2.1) is unclear. It doesn't have much to do with the interface body. At first, I thought it just an accident that should have been deleted when the USE inside of the interface body was added. On further thought, it might be for the actual arguments in the subsequent invocation of JOE. If that is the intent, it would be clearer if the invocation of JOE were added to the same code block (possibly after an ellipsis). The descriptive words could then be modified to reflect the change. As is, the introductory sentence for the first code block just says that it is an interface body, but then the first thing in the code block has nothing to do with the interface body. issue 232 - meaning of BINDNAME= Note 12.33 in 12.5.2.1 appears to assume a specific meaning for BINDNAME=, without ever stating that assumption. Otherwise the leap from talking about the number of BINDNAME= bind-specs to the number of external bind names is a complete non sequitur. Consider this the editor's attempt to appeal what he considers an unsatisfactory resolution of issue 156. I can accept that the feature is desired. I can also accept that the feature has aspects that are very processor-dependent. But I strongly argue that the normative text needs to say *SOMETHING* about what the feature is. Otherwise, it does not achieve its stated objective of standardizing anything except that there is a feature called BINDNAME= with strange restrictions on where it may be used. As is, this is not at all like kind parameters. The specific values of kind parameters are processor dependent, but the standard at least defines the concept - that kind parameters designate representations. For BINDNAME=, the normative text says *NOTHING*, and the note about how it might be used just emphasizes that there are no requirements. Its effects don't even have to be limited to the procedure that it is attached to; for all the standard says, that's just a handy place to put some syntax that is completely unrelated to the procedure. We ought to at least be able to say that BINDNAME= has something to do with the name(s) or means by which a procedure could be invoked, even if the details are processor-dependent. If we aren't going to say even that much, then every place that assumes it (like note 12.33) had better state the assumption. paper 99-263r1, import issue 233 - host association of defined operators Should the IMPORT statement allow defined operators as well as names? The USE statement does. Now that I think of it, are defined operators ever host-associated? From a quick skim of 14.6.1.3, it doesn't appear to me that they are. If that is correct, I find this difference between USE and host association puzzling. If that is incorrect, we better fix the inconsistency in description. Looks like the defined operators in USE are new to f2k, so at least its not an f95 interp question (I wasn't sure until I looked). issue 234 - async and import Can the asyncronous attribute be respecified for an entity imported into an interface body? The above words in 12.3.2.1 say not. The first note in 14.6.1.3 says it may, with no exception for the interface body case. Also, shouldn't that same note mention VOLATILE? I don't see the volatile statement listed in the numbered list in 14.6.1.3, so I assume it works like ASYNCHROUNOUS in thie regard. issue 235 - host association and interface bodies The above 2nd note in 14.6.1.3 no longer appears to be correct. paper 99-267, type-param-value issue 236 - intro to type-param-value Section 4.2 needs work on its transition of subject. The first part of the section talks about what type parameters are and how they are used. We then jump into the bnf for type-param-value. Whereas I agree that bnf can fit here, it needs a better introduction/transition. Something to introduce that we are now talking about how to specify the values. The two sentences deleted from this section by 99-267 were the only ones that even mentioned the specification of type parameter values. They may have been redundant/vacuous, but this needs something, probably as a lead-in paragraph before the bnf. Not much - just a sentence or two, but I don't have a good sentence at hand. And the sentence above this note - about agreement of the kind of the type parameters - just doesn't fit here at all. I think it was better in 4.5.5. This does only apply to derived types; thats the only place where we even define an integer kind of a type parameter. We haven't yet defined enough of the concepts for this to make any sense here. What is the integer kind of a type parameter? What defines a correspondence between a type parameter value and a type parameter? paper 99-273, I/O rounding modes issue 237 - compatable rounding mode A collection of issues about compatable rounding mode. First, it seems anomalous that the exact behavior of COMPATABLE is specified, whereas that of NEAREST is not. The processor can make NEAREST like IEEE or it can do about anything else with it. The requirement that NEAREST do IEEE round-to-nearest if it is supported is circular; if thats not how the processor does NEAREST, it just says that it isn't supported. But we specify exactly what a processor must do for COMPATABLE. There are no conditions. If we are willing to specify that much detail for compatable, why not specify it for NEAREST also? Note that this is I/O rounding only, so its not a matter of hardware; its a matter of the I/O library. I am concerned about a specification that depends on exact equality (of the mid-point). We tell users not to do that. Perhaps that is why we waffled on the IEEE case. If so, have we done anything to address that, or did we decide to ignore it in one case, but worry about it in the other. For example, what if a value to be output is stored in a temporary register with extra precision. And for input, how is the processor going to determine that a decimal value is exactly halfway between two representable binary values? We have left no leeway for approximations here. And as soon as we allow approximations, then the distinction between COMPATABLE and NEAREST becomes confusing. Most of the discussion about this option has been for the case of output. I'm dubious that input has been carefully considered. However the wording of the draft uses terminology that appears to assume input (it talks about being between two representable values - that's a terminology we use for internal values, not for decimal ones). But this is all in a section that applies equally to input and output. This needs at least clarification, and possibly fixing. Finally, and least importantly, the sentence defining the behavior is a little weak grammatically. But I don't see it as worth fixing until the other issues are addressed. SO I didn't bother.