J3/01-191 Date: 25 Apr 2001 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 01-011r1 and in the J3 notes of 01-007r1. These changes add 19 new issues, resolve 41, and change 2. This makes a total of 332 issues, 301 of which have been resolved, and 31 of which remain. I. Resolved issues paper 01-105r2 resolved 313 paper 01-110r2 resolved 307 paper 01-112 resolved 310 paper 01-113r2 resolved 312 paper 01-115r1 resolved 287, 288, 294, 296, and 290 paper 01-122r1 resolved 309 paper 01-123r2 resolved 304 paper 01-124r1 resolved 119 paper 01-125r1 resolved 259 paper 01-127 resolved 61 paper 01-130r1 resolved 212 paper 01-132r2 resolved 283 paper 01-162r2 resolved 5 and 6 paper 01-164 resolved 260 and 267 paper 01-167r2 resolved 240, 242, 248, 254, and 264 paper 01-168r1 resolved 160, 204, and 239 paper 01-169r1 resolved 161 paper 01-171r1 resolved 30, 305, and 306 paper 01-174 resolved 250 paper 01-181 resolved 144, 177, and 168 paper 01-182r2 resolved 243 paper 01-183r1 resolved 217 and 245 paper 01-185r1 resolved 276 paper 01-186r1 resolved 253 II. Changed unresolved issues paper 01-111r3 issue 308 modified as specified in the paper. paper 01-116r3 issue 311 - Annex B is obsolete After deleting the existing note text as specified in the paper, replaced it with the following: It is a little confusing that Annex B mentions only changes relative to F90. We voted not to detail the deletions in f77 (a decision I heartily agree with), but I'd think that F95 merits mention here, if only to say that all these deletions and obsolescnences were as of F95 and that f2k has no additional ones. Otherwise, the descriptive jump from f90 to f2k is confusing and makes one wonder about the role of f95. There were also a few issues that were modified in one paper, but subsequently resolved by another paper in the same meeting. Those are not listed here. III. New unresolved issues paper 01-110r2 issue 314 - io_modes The new item specified in the paper is numbered 314 paper 01-123r2 issue 315 - entities/objects The new item specified in the paper is numbered 315 paper 01-105r2 issue 316 - derived type io Even after my attempts at patchwork, the structure of the first sentence of the above para in 14.1.2.3 is pretty convoluted. For example, is there any reason why there are two separate "if" clauses, in different places in the sentence, one with a list of two conditions, and one with a third condition? I suspect this would be clearer with a numbered list. paper 01-147r1 issue 317 - assignment of allocatable derived type components Is it intentional that the derived type assignment fix of paper 01-147r1 fails to fix the case of allocatable derived type components? It seems odd and confusing to use intrinsic assignment for an allocatable component while using the type-bound defined assignment for nonallocatable components of the same type. I suspect this to be an accidental omission, but it is a technical question rather than editorial. paper 01-163r1 issue 318 - subobjects of local variables Should a subobject of a local variable also be considered a local variable? The glossary entry seems to imply so. This might avoid some cases of "or a subobject thereof". If we don't want to change this definition, we might want to change the one in the glossary so that they agree on this point. paper 01-185r1 issue 319 - identifiers The paper's item on this subject is numbered 319. paper 01-178r1 issue 320 - multiple definitions of object-name We now have two different definitions of the bnf term . We don't do that for anything else (I don't think so, anyway. Am I wrong?); it causes ambiguity. There is the definition above (R506) and the implicit definition from the default syntax rule. Nothing says that the above definition overrides the default syntax rule - we just have two definitions. The above rule has the constraint attached - the one from the default syntax rule doesn't. Thus, for example, it is ambiguous whether the constraint applies to the in R602. Ambiguous bnf seems like a bad idea. issue 321 - SAVE on POINTER statement The paper's item on this subject is numbered 321. Added the following extra para. The editor adds that he would interpret the above as already allowing procedure pointers. I see nothing restricting against them. Even if the constraint on object-name applies (see issue 320), I would have thought that a procedure pointer was a data object (and a variable). If it isn't, then we have problems in multiple other places. For example, it would be quite a surprise if procedure pointers couldn't be in COMMON (which allows only variables). Perhaps one fix is to make sure that the definitions of data object and variable allow procedure pointers. Otherwise, we better check for other places where procedure pointers need to be explicitly allowed. issue 322 - procedure pointer and variable The paper's item on this subject is numbered 322. Added the following extra para. See related comments in issue 321. And in fixing, don't forget that a procedure pointer may be a component. paper 01-132r2 issue 323 - type parameter keyword in structure constructors The paper's item on this subject is numbered 323. Added the following extra para. The editor adds that he doesn't see where type parameter keywords are used in structure constructors other than in a derived type specifier (which is covered). Perhaps this was intended to refer to a derived type definition. But there it's not used as a keyword (any more than a reference to a variable is a keyword). issue 324 - host vs host scoping unit It seems strange to me that we need two different terms: "host" and "host scoping unit", which mean the same thing (even if the definitions have minor wording differences). The document does appear to use both forms widely, which is perhaps unfortunate, but more bother to fix than seems worthwhile. If we are to have the two separate terms in the glossary, might we at least make one of them refer to the other so that it's clear that they mean the same thing instead of defining them using words just different enough to make someone wonder what the difference is? Perhaps we could just define "host" as short for "host scoping unit" - like we define "object" as short for "data object". not associated with any paper issue 325 - use of float as a name in example Am I the only one who thinks it poor style for this example to use a parameter name that is the same as the name of a standard intrinsic? Are we trying to encourage such a confusing thing? paper 01-114r2 issue 326 - result characteristics The paper's item on this subject is numbered 326. Added the following extra para. The editor notes that actual arguments don't generally have characteristics - the term "characteristics" is used only in reference to procedures, function results, and dummy things. issue 327 - result of NULL The paper's item on this subject is numbered 327. paper 01-115r1 issue 328 - scope of generic-spec Shouldn't this at least be mentioned in the clause about scope (14)? This may be part of what issue 319 is about, but it seemed worth noting here (4.5.1.5) also. Also, I hope there is somewhere that explains what it means for the generic-spec of an operator to be in scope. This seems like a pretty subtle place and way to say that type-bound operators and assignments "stick" with data objects of the type. Perhaps it is said more clearly elsewhere. And for the assignment symbol and intrinsic operators, this sounds like it contradicts 14.4 and 14.5, which say those are global, though perhaps I'm misinterpreting things here. issue 329 - generic tbp overriding vs extending I can't imagine that the above sentence in 4.5.3.2 actually is intended to mean what it says. Apparently if I inherit a generic binding to a pure procedure and then add a generic binding to a non-pure one, then that extends the generic? I don't believe it. I presume that there are 3 possibilities for a generic binding that has the same generic-spec as an inherited binding. 1) The new one may override 2) It may extend, or 3) It may be illegal. This sentence ignores the illegal cases and sounds like they extend the generic. It may be that we technically disallow the illegal cases elsewhere (I didn't search), but even if so, this sentence is misleading. It needs to at least qualify that it is talking only about bindings that are allowed by the rules of (whereever they might be). If there aren't such rules, then this sentence is just plain wrong. issue 330 abstract-interface-name I did the edit to add a bnf definition of in 12.3.2.3 as specified, but it has the same problem as the definition of discussed in issue 320. There is nothing to make this definition override the implicit one - they just conflict. issue 331 generic tbp references Both the above items in 12.4 have the common failing of trying to squeeze too much into a single sentence. At least that's what I attribute the problem to. In any case, it ends up hard to tell what modifies what, and thus hard to interpret the sentence. I doubt that "whose is the same as " is intended to modify , but that's how the sentences read; not that they make any sense that way. not associated with any paper issue 332 - missing constraint on associate construct Shouldn't R823 have a constraint like the 2nd one after R818? I don't see how one can argue that the one on R818 applies.