J3/00-310 Date: 13 Oct 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-011R3 and in the J3 notes of 00-007R3. These changes add 21 new issues, resolve 25, and change 4. This makes a total of 303 issues, 228 of which have been resolved, and 75 of which remain. I. Resolved issues 00-007r3 resolved issue 225. Paper 00-236r1 resolved issue 273. Paper 00-238r1 resolved issue 281. Paper 00-239r1 resolved issue 280. Paper 00-256r2 resolved issue 251. Paper 00-258 resolved issue 83. Paper 00-263r1 resolved issue 265. Paper 00-256r2 resolved issue 252. Paper 00-266r1 resolved issues 255 and 277-279. Paper 00-267r2 resolved issue 244. Paper 00-276r2 resolved issues 17-19. Paper 00-278 resolved issues 270-271. Paper 00-283 resolved issue 257. Paper 00-285r2 resolved issue 249. Paper 00-266r1 resolved issues 145, 274, and 275. Paper 00-290 resolved issue 122. Paper 00-294r2 resolved issue 209. II. Changed unresolved issues paper 00-241r1 issue 267 changed as specified in the paper. paper 00-242r1 issue 237 changed as specified in the paper. paper 00-291r1 issue 124 changed as specified in the paper. Plus added one more sentence noting that it might not be a problem. paper 00-250r3 issue 61. Old content deleted and replaced with Paper 00-250r3 resolved the previous issues with the example in C.1.3, but I now notice a separate issue. The example looks like code, but has a bunch of lines at the end that are isolated data references that aren't part of any statement. That's confusing and different from how we've handled simillar things elsewhere. They either need to be made into complete statements or words need to be added to label them as data references based on the preceding stuff. See the example in C.1.5, where complete statements were used. III. New unresolved issues paper 00-281r1 issue 283 - Glossary entry for characteristics The glossary entry for characteristics did not get updated along with the normative definition. Wouldn't surprise me at all to find other glossary entries similarly out of date, but I happened to notice this one. paper 00-250r3 issue 284 - Accessibility of inherited components The above material in 4.5.1.7 about accessibility of components is not correct for inherited components. I asked about this general question on the floor and was told that it was covered. On more leisurely study, I conclude that the coverage is inadequate. It is true that 4.5.3.1 says that inherited components retain their attributes. But that just means we have two contradictory sections; having it right in one section isn't good enough. The above para doesn't allow for any exceptions. It won't work, by the way, to claim that the explict declaration for the inherited component is in the declaration of the parent type - the inherited component might be using the default accessibility for the components of the parent type. Although it appears to me that we need to say something here about different treatment for inherited components, the following para on the parent component seems largely redundant. The parent component *DOES* seem to be covered by the para above this note - its accessibility is the default unless explicitly declared by an access-spec for the component. The only difference is in the syntax of where an access-spec goes. I guess that syntax needs to be mentioned somewhere, but I don't see that it merits repeating the rest of the para. This area may have suffered in coherence because of two different papers having edits in the same area - one that added new material, and another attempted to re-organize the presentation of the old material. paper 00-296r1 issue 285 - Association status As specified in the paper. Plus the following para. The editor adds that the term "associating variable" isn't defined, though that might be part of what the first para of this issue is about. He also thinks that the phrase "During execution" adds nothing useful to "when". And he isn't comfortable with the tense confusion of "was currently". issue 286 - Inheritance association Section 14.6.1 lists inheritance association as a form of name association. It seems anomalous then that 16.6.2.1.4 twice says "name associated...or inheritance associated". paper 00-233r2 (Yes, this paper had most of the new unresolved issues for the whole meeting. Type bound procs are pretty complicated, and one shouldn't expect to be able to just slip in genericity without a fair amount of work. Add that to integration issues with derived type io... I think this task was seriously underestimated.) issue 287 - Generic type bound procs It seems anomalous that the GENERIC form of proc-binding-stmt is allowed (indeed required) for dtio, but is not allowed for other bindings. I suspect there might be intent to change this in the future. But for now it just looks anomalous and almost bound to provoke questions and confusions. It is an inconsistency with no obvious (to me, and I suspect to most users) reason. issue 288 - Constraint on generic tbps My initial thought about the above two constraints on proc-binding-stmts was to wonder why they were different. Doesn't the first one (without the condition on PROCEDURE being specified) cover both cases? As written, this implies that the GENERIC form requires the proc-interface-name when a NULL is overriding, even though the PROCEDURE form prohibits it. I suppose that might indeed be the intent, though it's confusing. Is a user actually supposed to remember all these distinctions or are we assumimg that he will be coding with the standard document open? I then noticed a difference that isn't there and needs to be. The generic form does not have a unique binding that can be referred to with a definite article. It has a binding-list. issue 289 - Overly complicated constraint on tbps The above constraint about multiple bindings in a dtio-generic-spec is likely to confuse people by being a lot more complicated than is needed. Unless I'm confused (quite possible), this constraint just means that the dtv arguments are required to have different kind type parameters. The constraint referencing 9.5.4.4.3.already tied down everything else pertinent, making most of 14.1.2.3 moot for this. And it's a strangely narrow constraint anyway. It constrains only against duplication in a single proc-binding-stmt, but allows the same duplication if we use two separate statements. Was it intended for the constraint to cover that case? I wouldn't interpret it as doing so as written. Same comment about the new constraint (last one) on dtio-generic-spec (R1208). It took me multiple readings to figure out what it was saying, which turned out to be pretty simple. Why is there a constraint on the dtio-generic interface block when there is no corresponding constraint for the same issue in other generic interface blocks? If we are going to phrase the constraint this broadly, complete with subtle issues about disambiguation by keyword and position, then why don't we go ahead and apply it broadly? And the R1208 constraint is similarly and strangely narrow. It constrains against an interface body that conflicts with a generic binding, but doesn't constrain against two interface bodies conflicting. issue 290 - resolving dtio references The issue specified in the paper is numbered 290. Also added the following to it: Also this subclause is a little weak on introduction to establish context. We just start talking about the data transfer without even introducing how the subject of data transfer came up. One presumes that there must be a data transfer statement somewhere in the picture, and in fact that it establishes what scoping unit we are talking about. But this section never says that. The question might be less than completely trivial in some cases (say when a dtio procedure does recursive io). issue 291 - passed object dummy arg (This doesn't really arise from any new paper - I just noticed it while trying (unsucessfully) to figure out the part of paper 00-233r2 that turned into issue 290). What does it mean for the passed object dummy argument to "have the same type" as the type being defined? Consider that in many of the "interesting" cases the dummy argument will be polymorphic. In fact, I can't come up with any way of using PASS_OBJ unless the dummy is polymorphic; should that perhaps be a requirement? issue 292 - sets of bindings are distinct from bindings? We define a type-bound generic interface to be a set of procedure bindings. Why then is it listed above as though it were a distinct inheritable thing different from the bindings. issue 293 - non_overridable for generics Multiple issues here, but I'll just assign one number. The way the first para of 4.5.3.2 has been edited, it now explicitly excludes generics. And this appears to be the only place where we say what non_overridable means. It would be good if it meant something for generics, since we do have it in the syntax for them. While I'm looking here I'll note the unrelated issue that the last para of 4.5.3.2 talks about the kind type parameters of the derived type argument of a binding. I don't think a binding has arguments - it's the procedure bound to that has arguments. And "the derived type argument" is an awfully "fragile" specification. It won't generalize well at all to generics other than dtio...in fact, it doesn't even generalize enough cover dtio changes made earlier in this same meeting (there are now 2 derived type args). This same problem occurs twice in 14.1.2.4.3. I'd note that the first sentence of the last para of 4.5.3.2 parses oddly (we aren't meaning to imply that the derived type arguments are inherited from the parent type are we?), but the other parts of this issue are unlikely to leave that phrasing as is. issue 294 - Null and proc-binding Papers 00-233r2 and 00-293 made incompatible changes in Table 7.2. I has already done the one from 00-293 before coming to 00-233r2. Probably easy to integrate, but I'll let someone else do it. Perhaps as simple as appending -stmt to proc-binding 3 times. issue 295 - Other requirements (Not new to paper 00-233r2, but...) The "other requirements" in the above para in 9.5.4.4.3 is spectacularly unhelpful. This begs for at least a citation of the section where they are specified. issue 296 - dtio interface blocks Several things here (12.3.2.1.3). What does "as with generic names" modify? Apparently "several subroutines", which I doubt was intended. Further, I don't think subroutines are defined in interface blocks; subroutines are defined by subprograms (or by means outside of Fortran). Also, is the dtio-generic-spec generic only if there are several subroutines? That's what this says, but I'd think it would be generic even if there were only one (particularly if there were also generic bindings). And I'm not entirely comfortable with "in exact analogy" as a normative description (here and in 4.5.1.6). But grep does reveal that we say the same thing about defined operators (and did so in f90), so I guess it must be perfect. :-) issue 297 - missing rules for dtio generics It's nice that the first sentence of 14.1.2.3 now says that the section now has rules for dtio generics. It might be nicer if it were teling the truth. Where in the section are these rules? issue 298 - resolving dtio refs Although I already find it awfully hard to read the above sentence in 14.1.2.4.3, I'm afraid it isn't precise enough. The first "and" is written as though it connected two independent conditions. I think you want the dtio-generic-spec to be in the specified interface - having the right kind of dtio-generic-spec in the interface for som eother type won't do. As an aside, the clarity isn't helped by using "type of data transfer" is the same sentence where the word "type" is being used several times with a completely different meaning. issue 299 - uniquely resolving dtio What happens if both of the above conditions are satisfied? The specs of 00-233r2 say this shouldn't be allowed, but I don't see such a prohibition in the edits. I see a constraint to R1208 which might be aimed at indirectly prohibiting this, but it appears to miss the mark by quite a bit. We could have an extensible type with no generic bindings, and have an interface body with dtio-generic-specs for that type. The dtv in those interfaces will be type compatible with all types extended from this type. Now extend the type and add a generic dtio binding to the extended type. For effective items with a declared type of this extended type, it appears to me that both condistions are satisfied without violating any rules. paper 00-277r2 issue 300 - Final keyword "May" implies permission for the programmer to do something. It seems unlikely that this is the intended meaning here (4.5.1.10). I also doubt that more than one of them is executed for a single object. I am also surprised that we restrict finalization to data objects; I thought that the most important need for this feature was for entities other than objects. Perhaps our definition of "object" is bad and should be broader - I can't offhand recall why we define it so narrowly, and people keep forgetting the narrow definition and using the term more broadly. Perhaps it should be defined the way we keep wanting to use it. The object issue applies throughout the whole of 00-277r2; I'm not going to list each place. issue 301 - Finalization in nonexecutable scoping units Is there an issue here with scoping units that aren't executable? That would include modules, interface bodies, and block data. I haven't carefully thought about it, but the casual way that the above sentence ignores the question makes me wonder issue 302 - Finalization of allocatable components. Is the above para in 6.3.3.1 really meant to be a requirement on the program (as opposed to on the processor)? I doubt it. But see 1.6.0. And suppose the component is not finalizable? We have no definition of what it means to finalize a nonfinalizable entity. issue 303 - purity of specification expressions. Don't we need something somewhere to require that finalization be pure in specification expressions? The text added to 12.6 doesn't cover finalizations of the above para (in 4.5.11) because they aren't references *in* a pure subprogram; they finalize the result at some time after the procedure has completed. I can't offhand think of any other places where final procedures might violate purity in ways not restricted against, but I could have missed something.