J3/03-142 Date: 12 Mar 2003 To: J3 From: Richard Maine Subject: Edits for 2.5, 2.6, 2.11, and 2.12(T6) of US comments All edits herein are with respect to J3/02-007r3. I. It is proposed that the edits described in J3/02-299 be incorporated into the next 007 draft. Those edits are not detailed here because they do not affect the monochrome paper document at all. They are edits to the underlying LaTeX that have the effect of 1. Turning off coloration in the Annexes. 2. Providing an option to turn off the gray backgrounds for notes (defaulted to the same appearance as now). 3. Making links in the contents and index "live" for interactive viewing. II. It is also proposed that a BNF xref, as described in 03-107r2 section 2.6 be added. Exact edits are not listed here because most of them are automatically generated. See the sample in paper 02-256, except that the script provided puts the defining R number to the left of the name instead of in parens to the right. In cases where a BNF term has no R number because it is defined by an implicit rule, the defining R number is replaced by a long dash. [531:end-of-page] Start a new page with an unnumbered section heading "Syntax rule cross-reference", followed by the xrefs auto-generated by Kurt's BNFxref.pl script. Alternative. Paper 03-107r2 said "added to Annex D", which is what the above edit does. I'm not sure whether that was literally intended; it seems a little odd to switch in the middle of an Annex and the unnumbered section heading seems an awkward hack. There isn't a corresponding heading for the first part of Annex D. (The "Index of syntax rules" is the annex title). An alternative edit would be to put the same material in the same place, but as a separate Annex with "Syntax rule cross-reference" as the title. In that case, the new Annex would also be added to the list on page xiv and to the contents. III. The following edits are suggested for the issue mentioned in 03-107r1 section 2.5. Note that paper 03-117 proposes incompatible edits; we should not pass both versions. (This implements exactly what 03-107r2 recommended - namely that BIND(C) is mandatory with enum. I'm not 100% certain whether that was the literal intent or whether it was intended that the BIND(C) be implicit. Either option seems at least plausible, and it is trivial to modify these edits either way. It looks slightly odd to require explicit specification of the only option, though I can see that could facilitate future addition of other options.) [62:1] Delete this line [62:11] "(1) If BIND(C) is specified, the" -> "The". Also outdent the whole para to the level of the normal text. [62:19-20] Delete these 2 lines. [63:Note 4.63+1-4] replace the first 4 lines with "Example of an enumeration definition:" [63:Note 4.63+9-13] Delete these 4 lines. [63:Note 4.63+14-17] Uncomment these 4 lines and make them a normal note paragraph. (This edit isn't strictly necessary, but I think it improves the presentation.) IV. The following edits are suggested for the wording problems mentioned in 03-107r1 section 2.11. W8. This is a minor revision of an edit originally suggested in 02-287 (but deleted from 02-287r1). [399:37-38] "Within the scope of a FORALL construct, an" -> "An" [399:38] Insert "contained" before the first "FORALL". [399:39] "a" -> "any of its"; "construct" -> "constructs" W9. [402:1-9] replace this para with "If an external or dummy procedure with an implicit interface is accessed via host association, then it shall have the EXTERNAL attribute in the host scoping unit; if it is invoked as a function in the inner scoping unit, its type and type parameters shall be established in the host scoping unit. The type and type parameters of a function with the EXTERNAL attribute are established in a scoping unit if that scoping unit explicitly declares them, invokes the function, accesses the function from a module, or accesses the function from a host in which its type and type parameters are established. If an intrinsic procedure is accessed via host association, then it shall be established to be intrinsic in the host scoping unit. An intrinsic procedure is established to be intrinsic in a scoping unit if that scoping unit explicitly gives it the INTRINSIC attribute, invokes it as an intrinsic procedure, accesses it from a module, or accesses it from a host in which it is established to be intrinsic." Note the following points; I mention these here because it is easy to get this stuff wrong (it has been the subject of multiple interps). So if the above edits for this item are redone, be sure to consider these issues. 1. We allow the type and type parameters of a function to be unknown as long as we don't invoke the function; we even allow it to be unknown whether it is a function or subroutine. 2. The original test used the phrases "invoked as a function" and "used as a function". If these mean anything different, I couldn't deduce the difference. 3. We don't have to repeat the details of 249:1-5 here. I see no benefit to compensate for the added complexity and chance for inconsistency introduced by the repetition. 4. Don't forget about statement functions; a few of the above words are to avoid saying incorrect things about statement functions. (Statement functions can get implicitly typed without being invoked). 5. Looks to me like the original text failed to cover the case where X is the host of Y, which is the host of Z, and things are established in X by any way other than X using M. The above words cover this. V. The following edits are suggested for the technical problems mentioned in 03-107r1 section 2.12. T5 This item will be covered in a separate paper. T6 The following is a somewhat hurried job of minimalist edits for this item, but it ought to be better than what is in the existing draft (nothing). [261:13+] Insert new paras "If a other than a appear, it specifies that the declared procedures or procedure pointers have that attribute. These attributes are described in 5.1.2. If a with a NAME= appears, it specifies a binding label as described in 15.4.1. A without a NAME= is allowed, but is redundant with the required by C1218. If => null-init appears in a in a , it specifies that the initial association status of the corresponding procedure entity is disassociated. It also implies the SAVE attribute, which may be reaffirmed by explicit use of the SAVE attribute in the or by a SAVE statement." (Am I correct about the proc-language-binding-spec without a NAME=? It sure looks to me like it is redundant). T8 This item is addressed in 03-105r1.