J3/01-102 Date: 21 Dec 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 01-011 and in the J3 notes of 01-007. These changes add 8 new issues, resolve 32, and change 3. This makes a total of 313 issues, 260 of which have been resolved, and 53 of which remain. Issues 145, 273, 274, and 275 were previously resolved and removed from the 007, but were accidentally left in the 011. They have now been removed. These are not included in the count of issues resolved with this revision; they were included in the count of issues previously resolved. Issues 156 and 280 were previously resolved and indicated as such in the 011, but were accidentally left in the 007. They are removed in 01-007. These are also not included in the counts of issues resolved with this revision. I. Resolved issues paper 00-311r1 resolved 289, 291, 292, and 297. paper 00-312r2 resolved 300-303. paper 00-314r2 resolved 208 and 221. paper 00-320r2 resolved 293, 298, and 299. paper 00-326 resolved 272. paper 00-327r1 resolved 285 and 286 paper 00-333 resolved 284. paper 00-334 resolved 94 and 232. paper 00-335 resolved 151. paper 00-336 resolved 228. paper 00-338r2 resolved 218, 219, 238. paper 00-339r2 resolved 126. paper 00-340r1 resolved 90. paper 00-341r1 resolved 2. paper 00-342r1 resolved 216. paper 00-343 resolved 110. paper 00-345 resolved 266. paper 00-346r1 resolved 211. paper 00-354r1 resolved 282. II. Changed unresolved issues paper 00-311r2 changed issue 290 as directed in the paper. paper 00-344 changed issue 294 as directed in the paper. paper 00-351 issue 262 - Intrinsic Moved to the first page of section 13 and replaced the text with: Paper 00-351 worked on fixing the definition and use of "intrinsic", but does not appear to have completed the job. Some of the remaining fixes might involve more than purely editorial matters, so I didn't try to craft them on the fly. (Plus I want to flag this so that it gets a more throrough look). Specifically: The 2nd para of c13 acknowledges nonstandard intrinsic modules, but the first para and 13.1 ignore nonstandard intrinsic procedures. I presume the function categorizations here apply only to the standard intrinsic functions. It seems anomalous that the section headings for 13.13, 13.14, and 13.17 include the word "standard", but those for 13.1, 13.15, and 13.16 don't. I don't see the pattern here. (But perhaps all this would be improved by drastically cutting back on the mess that is the early parts of c13.) Of a more technical concern is the new definition of specification expression. Standard intrinsics are allowed, and non-intrinsics are allowed, but nonstandard intrinsics are disallowed (the definition specification function says that it is nonintrinsic). I *SERIOUSLY* doubt that this is intended. III. New unresolved issues paper 00-327r1 issue 304 - Associate name is not a data entity It's not new to paper 00-327r1, but that paper added the new case that I noticed. In 14.6.5 and throughout 8.1.4, the term "associate name" is used inappropriately. A name is not a data object or entity and does not have the attributes of one. The usage of these sections is confusing the name with the entity that it names. If one needs a term for this entity, perhaps "associate object" or "construct object" would do. paper 00-323r3 issue 305 - Connection properties in Annex C Paper 00-323r3 added a bunch of new connection properties (modes), but did not make corresponding changes in the Annex, including at least C.6.4 and C.6.5. Also, the terminology used for these in Annex C is different from that now used in the normative text (properties vs modes). issue 306 - Initial modes for child data transfer statements This could be 3 or 4 issues, but I'll group them. Sections 9.5.1.9-9.5.1.14 have repetitive descriptions about how the initial modes are determined. I almost wrote that these descriptions were wrong for child data transfer statements, but on careful study, I can't actually find a direct contradiction, so perhaps they are correct. Still, it is at least a subtle point. Section 9.5.4.4.3 says that the values are restored when the child is done, but it doesn't make it as clear as I'd like what happens when the child starts. I *THINK* it is saying that the values are reset to the initial ones, just like for a non-child statement, but I'm not sure. Seems like it would be worth making more explicit for dummies like me. In any case, though its not an error, I'd suggest eliminating the 6 copies in 9.5.1.9-14 of the material on initial modes. It would seem more concise to just reference 9.4 and 9.4.4.x instead of repeating it 6 times. (Among other things that would lower the number of places we need to be sure it's right). And while looking at 9.5.4.4.3, I see it looks out of sync with the new list of modes. The regularization paper didn't regularize this. Likewise 13.18.2.3 oddly omits delim. issue 307 - What does inquire really return? A naive reader such as myself has trouble in reconciling the statements about inquire in 9.8.1.18,24,25,28,29,30 versus those in 9.5.4.4.3. The 9.8.1.x sections say that inquire returns the values "in effect". Section 9.5.4.4.3, in particular note 9.44, says that io_mode has the "current" values (which sounds like the ones "in effect" to me), and that inquire returns the values from the most recent OPEN (or the default). issue 308 - Oddities for pad= in inquire Paper 00-323r3 deleted all mention of what the pad= specifier in inquire does if there is no connection or if the connection is not for formatted I/O. This seems unwise. I crafted words to restate the previously specified behavior. But this made me notice that the previous specification was...unusual. The "YES" above is not a typo; that's what the previous spec reduced to. I'd do the "obvious" fix for consistency except that this would be an incompatability with f95. This may deserve an interp unless I'm more confused than usual, which is possible. paper 00-313r3 issue 309 - Variable names and deferred length Variable names never have deferred length. paper 00-352 issue 310 - default-int-variable unused As mentioned on the floor, paper 00-352 removed all cases of the bnf term scalar-default-int-variable except for its definition (R608) and in the definition of assign in Annex B (which needs to be completely redone anyway; see issue 311). Ignoring Annex B as a separate issue, the fix is pretty trivial and obvious, but the editor doesn't think he should be deleting bnf definitions on his own. issue 311 - Annex B is obsolete (Not really related to paper 00-352, except insomuch as that paper helped draw my attention here). It might seem amusing that the Annex on obsolete features is obsolete, but I doubt that most readers of the standard will appreciate the humor. :-) This annex has mostly been ignored while revising material that it refers to. There might be some of this that is still correct, but I wouldn't trust any of it without carefully checking. I suggest the possibility that it is sufficient to describe the deleted features rather than giving edit diffs to effectively insert them. Specifically, keep B.1.0, but remove the B.1.x subsections. One could argue for expanding the material in B.1 to discuss possible conversions, just as B.2 does. It seems odd that we discuss conversion of the obsolescent features that are still in the language, but not of the deleted features. All we do for the deleted ones is give edits for undeleting them. While I acknowledge that many vendors will continue to implement the deleted features, they shouldn't need such explicit detail in the standard. Furthermore, we should not spend our time worrying about how to standardize any interactions between deleted features and new ones. If we craft exact edits to insert the deleted features, that's in essense what we will have to do. issue 312 - Additional kind arguments Paper 00-352 added additional arguments to several (12) intrinsic procedures. This should probably be noted in 1.5.1 much like the additional intrinsics. This could invalidate formerly standard user-written generic extensions. Not that I think it a big deal, but it is as pertinent as other incompatibilities noted. paper 00-320r2 issue 313 - wording in 14.1.2.4.3 Van notes that the above "that interface" in 14.1.2.4.3 refers to an interface not yet mentioned. This is an unfortunate result of moving some text here without adequately rewording it. And need to distinguish declared vs dynamic type in items 2 and 5.