12-173 To: J3 From: Van Snyder Subject: Problems with procedure identifiers and generics Date: 2012 October 05 1. Scope --------- The intention here is to clarify wording, not to change technical content. Some of it might already be OK, but I didn't want to overlook a potential problem. There appear to be some obvious problems, which are corrected here -- or maybe there aren't any problems. 2. Explicit interface ---------------------- In some places, the requirement for explicit interface is put on procedure names; in others, it's put on procedures. For consistency, apply the requirement to procedure names everywhere. According to 12.4.2.1p1, dummy and external procedures can only have explicit interface defined by interface bodies, not by procedure declaration statements. Procedure pointers aren't specified in 12.4.2.1 to have explicit interface. This contradicts 12.4.3.2p7 and 12.4.3.6p2. According to 16.3.5p1, argument keywords are only allowed if an explicit interface is specified by an interface body, not a procedure declaration statement. Edits: [4.5.5 C465 73: 16] Replace "that has an" by ", and shall have". [12.4.2.1p1 279:11-17] Replace the paragraph: "The interface of the identifier of a procedure is either explicit or implicit. It is explicit if it is the identifier of o an internal procedure, module procedure, or intrinsic procedure, and the identifier is neither a dummy procedure name nor a procedure pointer name, o a subroutine, or a function with a separate result name, within the the scoping unit that defines it or a scoping unit that accesses it by host association, o an external procedure for which an explicit interface is specified by an accessible or interface body, o a dummy procedure for which an explicit interface is specified by an accessible or interface body, or o a procedure pointer for which an explicit interface is specified by an accessible . Otherwise, the interface of the identifier is implicit. \obs{The interface of a statement function is always implicit.}" The obsolescent sentence about statement functions could be a note, or omitted, since it's covered by the "Otherwise" sentence. [7.2.2.4p8 160:16] Replace "is a" by "is the name of a". [12.4.2.2p1 279:19] In the correction from interpretation F08/0054, replace "the procedure shall" by "the identifier shall". [12.4.3.2 C1207 281:8] Insert "the name of" before "a"; replace "that has an" by "and shall have". [12.4.3.2 C1208 281:9] Replace "accessible as a module procedure" by "the name of an accessible module procedure". [12.4.3.6p1 287:5-6] Insert "names of" after "declares". Replace "entities" by "procedure entity names" {exclude }. [12.4.3.6p2 288:2] Replace "procedures" by "procedure names". [12.4.3.6p3 288:4-5] Replace "declared procedures or procedure pointers" by "declared names are names of procedures or procedure pointers that". [12.4.3.6p4 288:8] Replace "procedures" by "procedure names". [12.4.3.6p5 288:9] Replace "procedures" by "procedure names". [12.6.3.5 C1262 309:18] Insert "the name of" before "a". [12.7 C1280 312:26] Replace "its interface" by "the interface of its identifier". [16.3.5p1 442:4] Insert "as an argument keyword" before "only" so as not to prohibit the use of a dummy argument of a random procedure as a local identifier. [16.3.5p1 442:5-7] Allow argument keywords wherever an explicit interface is accessible, and not just one defined by the procedure or an interface body. Replace "If the procedure ... unit" by "If a procedure identifier has explicit interface (12.4.2.1) in a scoping unit, the argument keyword is accessible in the scoping unit for references to the procedure". [16.3.5p2 442:8-10] Delete the paragraph. Intrinsic procedures always have explicit interface, so the repair of 16.3.5p1 covers the first sentence. The second sentence repeats one in 16.3.5p1. 3. Generic identifiers ----------------------- 12.4.3.2 doesn't say what interface blocks do. Unlike 4.5.5p3, it doesn't say that a generic interface block declares a generic procedure. 12.4.3.4.1 doesn't say that a in a declares a generic identifier for the names in the . 12.4.3.4.1 is described entirely in terms of interface blocks, completely ignoring generic bindings. Edits: [4.5.5p3 74:17-18] Delete "a generic type-bound procedure, which is". {The term "generic type-bound procedure" is not used anywhere.} Replace "its specific type-bound procedures" by "the specific type-bound procedures identified by its ". [4.5.5p4 74:19] Delete "(specific or generic)" since the next sentence claims this binding is specific. Replace "generic type-bound interface" by "type-bound generic interface" (compare to 4.5.5p3). [12.4.3.2 280:7+] Insert paragraphs, explaining what interface blocks do, and replacing parts of 12.4.3.4.1 that are germane only to interface blocks: "An interface block collects interface bodies and procedure statements. Each interface body, or each in a procedure statement, identifies a specific procedure. "A generic interface block declares a generic interface for procedures identified by interface bodies or procedure statements within the interface block." {Compare to 4.5.5p3. This makes C1227 work correctly.} [12.4.3.4.1p1 283:3-5] Replace the paragraph, making it germane to generic interfaces established either by s or interface blocks: "A generic identifier of a generic interface is declared by a in a (4.5.5) or (12.4.3.2). The interface of a generic identifier is always explicit." [12.4.3.4.1p2 283:6] Insert "or " after "". Replace "interface block" by "generic interface". [12.4.3.4.1p3 283:11-13] Replace the paragraph: "A generic name is a generic identifier that refers to all the procedure names in the generic interface. A generic name may be the same as any of the procedure names in the generic interface. A in a or may be the same as any accessible generic identifier." [12.5.1 C1227 289:22] Insert "a generic name or" after "shall be". {There is no specification that an interface block declares a generic procedure, so by having only "the name of a procedure," C1227 prohibited referencing procedures using generic names.} 4. Definition of "accessible" ------------------------------ The term "accessible" is not defined in 1.3. Edits: [1.3.1+ 2:10+] Insert a subclause "1.3.1a <> of an identifier, whether it is a local identifier (16.3), or accessible by use association (11.2.2) or name association (16.5.1) \\ of an entity, whether its identifier is accessible" 5. Wording quibble ------------------- [12.4.3.6p6 288:14-16] Replace "entity" by "pointer" thrice.