J3/98-011R1 Date: 9 Nov 98 To: J3 From: R. Maine Subject: Editor's list of unresolved issues. This paper is a list of issues that the editor considers to be unresolved. Items may be deleted from this list when they are resolved, but the item numbers will not be re-used. Items in this list may have associated J3 internal notes in the document, though currently many do not. When there is a corresponding J3 note, the J3 note shall reference the item number. Thr first version of this document included the text of the J3 notes. Following suggestions from the floor, this version has been shortened by deleting all the text detailing the issues. That text remains in the J3 note, which is referenced herein. For those cases where there is not yet a corresponding J3 note in the document, or where the note does not include all of the relevant material, the detailed text remains here for now, with the intent that this text will later be moved into a J3 note (unless the issue is resolved first). Main references: 98-110 was changes from 97-007r1 to 98-007 98-144 was changes from 98-007 to 98-007r1 98-168 was changes from 98-007r1 to 98-007r2 98-205 was changes from 98-007r2 to 98-007r3. 1. Time dependent attributes Needs J3 note in 9.4.1.10. Raised in 98-110. About 97-262. In 9.4.1.10, 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. 2. More on time dependent attributes. Needs a J3 note in 5.1.2.12. Raised in 98-110 item 1. About 97-262. I find the wording in the first para of 5.1.2.12 a bit confusing. 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. My proposed wording is: "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. 3. I/O error handling. Needs J3 note in 9.4.4. Raised in 98-110 item 3. About 97-262. I don't really think you want to say in 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). 4. Pending I/O storage sequence affector. Unnumbered J3 note in 9.4.1.10 of 98-007r3. Raised in 98-110 item 4. About 97-262. 5. Direct and ultimate components. Unnumbered J3 note in 4.5.0 of 98-007r3. Raised in 98-110 item 6. About N1282. 6. Allocatable components and subobjects. Unnumbered J3 note in 6.1.2 of 98-007r3. Raised in 98-110 item 7. About N1282. 7. Automatic deallocation Unnumbered J3 note in 6.3.1.2. Raised in 98-110 item 8. About N1282. 8. Output of allocatable components. Needs J3 note in 9.4.2. Raisef in 98-110 item 9. About N1282. [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. 9. Initialization of objects with allocatable components. Needs J3 note. Raised in 98-110 item 10. About N1282 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. 10. Pointer and allocatable parameters. Needs J3 note. Raised in 98-110 item 11. About N1282. 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. 11. Execution of a process Needs a J3 note in 15.2. Raised in 98-110 item 12. About N1281. 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. 12. IEEE_SUPPORT_HALTING Needs J3 note in 15.9.25. Raised in 98-110 item 13. About N1281. 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 under 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. 13. Initial definition status of INTENT(OUT) dummies Needs J3 note in 14.7.5(6). Raised in 98-110 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. 14. Restrictions on dummy pointers and allocatables not present. Needs J3 note in 12.4.1.6. Raised in 98-110 item 15. Section 12.4.1.6 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. 15. Explain constraint on proc pointers. First unnumbered J3 note in 5.2 Raised in 98-144. About 98-121r1. (Not all of this explanation yet in the J3 note) The 2nd constraint after R523 needs explanation. Its also not clear that it is right. Suggestion that accessibility should not be prohibitted. 16. Procedure declaration stmt Second and 3rd unnumbered J3 notes in 5.2. Raised in 98-144. About 98-121r1. (Following extra material still needs to be added to the J3 note). Hmm. For that matter, I don't see anything outside of the note 5.20 that explains what "procedure ()" means at all. Nor do I see anything that explicitly says that "procedure (real)" means an implicit interface real function, or that "procedure (some_interface)" means a procedure with that interface. We just have the syntax, but we are missing words to say what the syntax means. Some of the cases are fairly obvious, but others are not. Even for the obvious cases, we should say the words instead of hoping that it is equally obvious to everyone. The only words I see have to do with whether the entity is a procedure pointer, dummy procedure, or external procedure. But I don't see any words about the interface being given to the specified names. 17. Parent type component. First unnumbered J3 note in 4.5.3. Raised in 98-168. About 98-145r2. 18. Component name conflicts. Second unnumbered J3 note in 4.5.3. Raised in 98-168. About 98-145r2. 19. Component or subobject. Unnumbered J3 note in 4.5.6. Raised in 98-168. About 98-145r2. 20. Constraints on polymorphic pointer assignment Unnumbered J3 note in 7.5.2 Raised in 98-168. About 98-145r2. (Following extra material still needs to be added to the J3 note). Also, I'm surprised that there are no compile-time constraints at all on type when target is polymorphic. We don't even demand compile-time checking that the target and pointer have the same base type. As a general problem in several places I'm concerned about the integration of pdts with inheritance. Looks to me like we didn't catch nearly all of the areas. I think that to integrate them properly, we are going to have to talk about "type and type parameters" together, rather than writing one set of requirements about types and then a separate set of requirements about the type parameters. It has been suggested elsewhere that we come up with terms to describe "type and type parameters" or "type and kind type parameters". It might simplify wording some of these things. Perhaps we might just suitably modify the definitions of declared type and dynamic type. We may need to modify them a little anyway. I don't think we ever quite explicitly said that the declared type of a non-polymorphic object type means (though its fairly obvious). 21. Scope of component names. Unnumbered J3 note in 14.1.2.5 Raised in 98-168. About 98-153. (Following extra material still needs to be added to the J3 note). On studying 14.0, 14.1.2, 14.1.2.5, and 14.1.3, it seems to me that components and type parameters are better described as having a scope of the derived type definition instead of saying that they have "the same scope as the derived type". I'd then interpret parts of section 14.1.2.5 as describing (quite adequately, I think) the limited contexts in which these names can be used outside of the derived type definition (that is, outside of their scope). In fact, I think we are forced to do type parameters this way because we need to have them included in the list (14.6.1.3) of things that block host association of host entities of the same name. The edits of paper 98-153 added type parameters to that list, but that only makes sense if type parameters have a scope of the derived type definition. So I've redescribed the scope of type parameters in that manner. If I've messed this up, let me know. 22. IEEE_SUPPORT intrinsics. Needs J3 note in 15.? Raised at meeting 146. About N1281. The IEEE_SUPPORT_* intrinsics in c15 appear to be impossible to use portably. As I interpret them, it is illegal to even write the call in the source code unless the data type returns true from IEEE_SUPPORT_DATATYPE, which you don't know until runtime. It doesn't look to me like protecting these calls with a conditional would make them legal - they might fail compilation. For the IEEE_SUPPORT_* calls, I'd think it obvious to allow them for all real kinds. There is an obvious value for them to return (.false.). Simillar issues with the other IEEE intrinsics, though for many of them, the value to return isn't obvious. Perhaps they should still be legal to write, but not to invoke (so that they can be protected by conditionals). 23. DTIO requirements on processor. J3 note 23 in 9.4.4.4.3. Raised in 98-205 item 23. About 98-189r2. 24. ROUND= and G J3 note 24 in 10.5.4.1.2. Raised in 98-205 item 24. About 98-190r2. 25. ROUND= and INQUIRE. J3 note 25 in 9.7.1.25. Raised in 98-205 item 25. About 98-190r2. 26. IEEE_SUPPORT_IO. J3 note 26 in 15.9.27. Raised in 98-190r2. 27. IEEE_SUPPORT restrictions. J3 note 27 in 15.9.27. Raised in 98-190r2. 28. DECIMAL and ROUND modes for internal files. J3 note 28 in 9.2.2.1. Raised in 98-199r1. 29. BLANK= in open statement. J3 note 29 in 9.3.4.6. Raised in 98-205. About 98-190r2. 30. ROUND= integration with DTIO. J3 note 30 in 9.7.1.25. Raised in 98-205. About 98-190r2. 31. DC edit descriptor. J3 note 31 in 10.8 Raised in 98-205. About 98-199r1. 32. ISO10646 character set. J3 note 32 in 13.15.96. Raised in 98-199r1. 33. Punctation in "ISO10646". J3 note 33 in 13.15.96. Raised in 98-205. About 98-199r1. 34. Copyright question. J3 note 34 in C.2.3. Raised in 98-191r1. 35. Syntax of contains J3 note 35 near R422. Raised in 98-205. About 98-186r1. 36. PASS_OBJ. J3 note 36 in 4.5.1. Raised in 98-205. About 98-186r1. 37. Constraints on proc components. J3 note 37 in 4.5.1. Raised in 98-205. About 98-186r1. 38. Select kind and type bound generics J3 note 38 in 4.5.1. Raised in 98-186r1. 39. Is CASE executable or not? J3 note 39 in 4.5.1. Raised in 98-205. About 98-186r1. 40. Acessibility of type bound procs J3 note 40 in 4.5..1.5. Raised in 98-205. About 98-186r1. 41. NULL for type-bound procs J3 note 41 in 4.5.1.5. Raised in 98-205. About 98-186r1. 42. Pure/nonpure overriding of type-bound procs. J3 note 42 in 4.5.3.2. Raised in 98-205. About 98-186r1. 43. Illegal examples for type bound procs J3 note 43 in 4.5.3.2. Raised in 98-205. About 98-186r1. 44. Accessibility of procedure bindings. J3 note 44 in 4.5.1.6. Raised in 98-205. About 98-186r1. 45. Determination of procedure bindings. J3 note 45 in 12.4. Raised in 98-205. About 98-186r1. 46. The term "type-bound procedure". J3 note 46 in 4.5.1.5. Raised in 98-205. About 98-186r1. 47. PASS_OBJ invocation. J3 note 47 in 12.4.1.1. Raised in 98-205. About 98-186r1. 48. Binding names. J3 note 48 in 14.1.2.5. Raised in 98-205. About 98-186r1. 49. Component accessibility and interp 32. J3 note 49 in 14.1.2.5 Raised in 98-205. About 98-186r1 and interp 32. 50. Glossary entry for binding. J3 note 50 in A. Raised in 98-205. About 98-186r1. 51. Glossary entry for passed object dummy arg. J3 note 51 in A. Raised in 98-205. About 98-186r1. 52. Glossary entry for type bound proc. J3 note 52 in A. Raised in 98-205. About 98-186r1. 53. Geneological terminology or not. J3 note 53 in 4.5.3. Raised in 98-205. About 98-184r2. 54. Syntax rules for CASE. J3 note 54 in 8.1.3.1 Raised in 98-205. About 98-184r2. 55. Evaluation of SELECT TYPE selector. J3 note 55 in 8.1.4.2. Raised in 98-205. About 98-184r2. 56. Associate-name in select type. J3 note 56 in 8.1.4.2. Raised in 98-205. About 98-184r2. 57. Nonextensible type in select type. J3 note 57 in 8.1.4.1. Raised in 98-205. About 98-184r2. 58. TYPE IN J3 note 58 in 8.1.4.2. Raised in 98-205. About 98-184r2. 59. TYPE DEFAULT and declared type of expressions. J3 note 59 in 8.1.4.2. Raised in 98-205. About 98-184r2. 60. Scope of associate-name. J3 note 60 in 14.1.3. Raised in 98-205. About 98-184r2.