J3/12-113r1 To: J3 From: Malcolm Cohen Subject: Further editorial changes for consideration Date: 2012 February 16 1. Introduction This paper contains further editorial suggestions for changes to the next revision of the standard or to the 007 (J3 document). Six straw votes are recorded, the results will be applied in the next 008. 2. Running subclause numbers This only affects the 007 J3 document, not the standard itself since these are not in fact permitted by the ISO guidelines. The worst is probably 1.3, where instead of plain "1.3" we have "1.3 TERMS AND DEFINITIONS". It is not entirely obvious just exactly how to fix this particular case (I would probably have to do some explicit resetting of the internal variables partway down the page). However, there are multiple problems throughout with running subclause numbers since despite what the package authors say, they do not produce the correct result. In particular, when a subclause begins at the top of a page because there is some room but not quite enough at the bottom of the previous page, and there are no other headers on that previous page, the footer of the previous page is changed to claim that the subclause begins on that page (and not the next page). See page 249 of 10-007r1 for an example. Also, the way that the subclause numbers is selected is weird anyway, it shows the first subclause heading on the page. This is not the same as the first subclause with text on the page! E.g. page 98. Even when there are several headings on the same page, it looks weird to see a low-level number like 10.7.5.3 but 10.8 also appears on the page. We could change to displaying the last subclause heading number instead: that would at least be consistent with the text, and make more sense since they are appearing in the footer - viz after the *LAST* one. But we would still be left with the wrong number in some cases (viz page 249). Since this would take some work but would either be fragile or imperfect, my recommendation is to delete these. They add almost nothing to the document (there are very few double-pages with no headings on them where any useful information in thereby conveyed). STRAW VOTE 1: Delete the (problematic and unofficial) running subclause numbers? Yes=8, No=0, Undecided=0. Result: These will be deleted. The clause name does not have any particular problems, apart from being unnecessary, uninformative, and against the ISO guidelines. My preference here is weaker than the previous case, but remains for deletion. STRAW VOTE 2: Delete the (unofficial and not particularly useful) running clause name? Yes=8, No=0, Undecided=0. Result: These will be deleted. 3. Indexing It has been brought to my attention that the definitions of the intrinsic procedures and entities in the intrinsic modules are not indexed. For intrinsic procedures the case for indexing is not particularly strong, as there is a complete table at the beginning of 13 and the definitions are in alphabetic order anyway. The case for indexing the IEEE module procedures is not much stronger - they all begin with IEEE_ and are alphabetic (and there are some tables); however the data types and named constants are not so well organised. Similarly for the C module entities. The entities in ISO_FORTRAN_ENV do not have any table, but all of them (types, procedures and named constants) are defined in alphabetic order. STRAW VOTE 3: Index the definitions of all intrinsic procedures and intrinsic module entities? Yes=7, No=0, Undecided=1. Result: These will be indexed. STRAW VOTE 4: Investigate reorganisation of the IEEE module descriptions to make it easier to find and understand the non-procedure entities (including rewriting 14.9p1) Yes=4, No=0, Future-Feature-Request=4, Undecided=0. Result: The decision is deferred to a future WG5 meeting. 4. Obsolescence It has been suggested that B.1p3 is superfluous and can (and should) be deleted, as the listed standards are all irrelevant (or at least unimportant) except for F90 which is explicitly mentioned in p4 as the one to look at. In discussion, it was suggested that the information in this paragraph would be useful and relevant to compatibility (1.6). STRAW VOTE 5: Move B.1p3, appropriately modified, into 1.6? Yes=8, No=0, Undecided=0. Result: B.1p3 will be moved. 5. Pointer-assigned We use the verb "to pointer-assign" both hyphenated and unhyphenated. (And have done so since F95 and probably F90.) The hyphenated version appears 5 times in 10-007r1: [299:31-32] "If it is a pointer, it shall not be allocated, deallocated, nullified, pointer-assigned, or supplied as an actual argument corresponding to an optional nonpointer dummy argument." [447:5] "The pointer is pointer-assigned to a target (7.2.2) that is associated or is specified with the TARGET attribute and, if allocatable, is allocated." [447:23] "(3) the pointer is pointer-assigned (7.2.2) to a disassociated pointer," [447:38] "(1) the pointer is pointer-assigned to a target that has an undefined association status," [447:39] "(2) the pointer is pointer-assigned to a target on a different image," The unhyphenated version appears 3 times in 10-007r1: [168:4-5] "It is possible to assign or pointer assign to the same object in different assignment statements in a FORALL construct." [295:NOTE 12.27] "However, allocating or pointer assigning such a dummy argument would require maintenance ..." [448:42] "Whatever its association status, a pointer always may be nullified, allocated, or pointer assigned." It has been suggested that we should hyphenate (or not) this consistently. The arguments are approximately - we do not usually hyphenate qualifiers with verbs, versus - when the subject (a pointer) appears in the same sentence, having two "pointer"s floating around that do different things is confusing to read. STRAW VOTE 6: "pointer-assign"/"pointer assign"/as is/defer to editor? Hyphenate=3, Dehyphenate=0, Asis=0, Undecided=5. Result: The verb will be consistently hyphenated. ===END===