J3/01-256 Date: 22 June 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-011r2 and in the J3 notes of 01-007r2. These changes add 7 new issues, resolve 30, and change 0. This makes a total of 339 issues, 331 of which have been resolved, and 8 of which remain. I. Resolved issues paper 01-205 resolved 320 and 330 paper 01-206 resolved 329 paper 01-212 resolved 317 paper 01-213r2 resolved 321 and 322 paper 01-215r1 resolved 127 and 128 paper 01-216 resolved 323 paper 01-217r1 resolved 318 paper 01-218r2 resolved 332 paper 01-223r2 resolved 124, 295, 314, and 262 paper 01-225r2 resolved 327 paper 01-226r1 resolved 331 paper 01-227r1 resolved 324 paper 01-228 resolved 315 paper 01-234r1 resolved 246 paper 01-235r1 resolved 213 paper 01-236 resolved 241 paper 01-238 resolved 171 paper 01-237r1 resolved 308 paper 01-242 resolved 311 paper 01-243r1 resolved 325 paper 01-246 resolved 237 paper 01-250 resolved 316 paper 01-251 resolved 328 paper 01-252r1 resolved 326 II. Changed unresolved issues none III. New unresolved issues paper 01-250 issue 333 - dtio description organization The material defining whether or not dtio happens for a particular effective io item is scattered all over the document in a way that makes it hard to find and understand. This is not entirely new to paper 01-250. Section 9.5.2 is the main place where the issue of expanding the i/o list to obtain effective items is discussed. This expansion depends, among other things, on whether dtio processing is done for an item. The section has several xrefs on that question, all pointing to 9.5.4.4.3. But 9.5.4.4.3 no longer has any material defining whether or not dtio processing happens. It xrefs 14.1.2.4.4, which is where the material really is. A section on resolving procedure references (14.1.2.4.4) seems a strange place for the material about whether dtio is permitted (list item 1). Further, the wording of that list item (in particular, the "that is") implies that it is summarizing material from elsewhere. This appears to be the only place where this is actually said, making the "that is" inappropriate. The 3rd para of 9.5.4.4.3 then contradicts itself in multiple ways. After citing 14.1.2.4.4, it refers to "other requirements" in 10.6.5 and 12.3.2. As best as I can see, this is irrelevant and misleading. If a dtio procedure is selected as described in 14.1.2.4.4, then dtio is done. Period. If there are other requirements that are not met, then the program is illegal. There are no valid cases in which a procedure is selected as described in 14, but is not used. Perhaps this para is a remnant of some former draft in which some of the material was not in 14.1.2.4.4. Finally, the 3rd para of 9.5.4.4.3 says that if a dtiop is used, the list items are not processed as described in 9.5.2. However, 9.5.2 specifically mentions the exceptions for dtio. So this statement is self-contradictory, in essense saying that if dtio processing is done, then dtio processing is not done. paper 01-229 issue 334 - procedure pointer assignment Should not much of the material in 7.5.2.2 (Procedure pointer assignment) be in constraints? I see in 01-229 that the "deconstraintification" of the second para was intentional, but the 3rd and 4th paras still seem suitable for constraints. Unless I am missing something (quite possible), the 5th para fails to consider deferred type parameters. The explanation in 01-229 says that this is for implicit interfaces (which rules out deferred type parameters), but the edits don't restrict it to that case. paper 01-251 issue 335 - conformability for defined ops Paper 01-251 deleted the conformability requirements for elemental defined binary ops and for elemental defined assignment in 7.3.2 and 7.5.1.6. I hope this is claimed to be covered elsewhere; if not, this will need fixing. issue 336 - dtio abbreviation Since the term "derived-type input/output generic specifier" (for any spelling of "input/output") appears nowhere in the standard, the utility of defining the scope of such a thing seems limited. The closest thing I can find is the bnf term dtio-generic-spec. Since the spelled out version never appears anywhere near the bnf term, the connection seems awfully weak. I've done nothing about this, but I don't think it acceptable as is. Although it may be reasonable to use dtio as an abbreviation for derived-type input/output, we owe the reader at least a clue of this; the average non-j3 member is unlikely to think this obvious. I consider I/O obvious (to the kind of people who have any chance of understanding the standard), but not dtio. To my knowledge nobody outside of J3 has ever used the term dtio. not associated with any new papers issue 337 - char-length param value Because C535 explicitly mentions the bnf term char-length, it "clearly" applies only to that bnf term, which is used only in the obsolescent form of the character specifier. I seriously doubt that was the intent. This also makes me notice that the bnf rule for char-length should probably be in obsolescent font. issue 338 - constraints on elemental The wording on the constraints in 12.7.1 could use improvement. See the wording style used in 12.6 for examples to emulate. Each constraint in 12.6 is careful to explicitly say that it applies to pure subprograms. In constrast, 12.7.1 relies on the sentence before the constraints to give the message that these apply only to elemental subprograms - and that sentence doesn't do a very good job of it. It refers to "the syntax rules defining elemental..." and then cites syntax rules that do not in fact say anything about elemental. It is a pretty subtle inference that this is trying to imply that after you add these constraints, the syntax rules then would define elemental subprograms. The words don't actually say this. Again, see the wording of all the constraints in 12.6 for examples of a far better job. That can easily be emulated here. issue 339 - external-file-unit The bnf term external-file-unit (R902) is now inappropriate because it can sometimes be used for files that are not external. Notably in child data transfer statements, where it might be connected to an internal unit. None of the occurances actually depend on this terminology. Several statements do use the bnf term in their bnf in places where an internal unit won't do. But none of them rely on the bnf for that restriction. The only way this syntax could refer to an internal unit is in a child data transfer statement and we prohibit all the questionable statements on a unit while a parent is active except inquire, which we handle explicitly). The defining thing about this bnf term is not that it represents an external file, but that it is a number. I suggest a global change of to , with a few corresponding "an" -> "a" changes where applicable. Is one case in c12 and several in c09. None elsewhere. Slight rewording of the first few paras of 9.4.0 also appropriate. Internal-file-unit is probably ok (and appears only one place in the document other than the 3 occurances in 9.4.0; that one place is in 16.7.7(6).