DRAFT J3/98-227r2 Date: 10th November 1998 To: J3 From: Malcolm Cohen Subject: Further edits for type-bound procedures This paper considers the issues raised by 98-205 and 98-207 and resolves them. (1) Item 1.1 from 98-207 No edit proposed in 98-207, no edit necessary. (2) Item 1.2 from 98-207 No edit proposed in 98-207, no edit necessary. (3) Item 1.3 from 98-207, typos in 98-007r3 Accept both proposed edits, viz: [239:34] Change "theh" to "the". [239:37] Add "(4.5.1)" after "passed-object dummy argument" (4) Item 1.4 from 98-207, section title No edit proposed, no edit necessary at this stage. (5) Item 1.5 from 98-207, override definition Accept proposed edit with typographical changes. [365:15+] Add to end of paragraph "(4.5.3) If a procedure is bound to an extensible type by the same as one that would have been inherited from the parent type, it overrides the one that would have been inherited from the parent type." (6) Issue 35, bnf for CONTAINS and PRIVATE [39:2-17] Replace with "[ [ ]" [41:22+] Insert "R435a <> [ ] [ ] ... R435b <> PRIVATE Constraint: A is permitted only if the type definition is within the specification part of a module." [252:28] After "may contain" add ", or it introduces the type-bound procedure part of a derived type definition (4.5.1)." (7) Issue 36, PASS_OBJ restrictions [41:7-9] Replace "If ... variable." with "Constraint: If PASS_OBJ is specified, the procedure component shall have an explicit interface that has a scalar nonpointer dummy variable of type . The first of these is the <> and shall be polymorphic if and only if is extensible." [41:32-34] Delete "If ... 12.4.1.1." [41:38+] Insert "Constraint: If PASS_OBJ is specified, the shall be to a procedure or abstract interface that has a scalar nonpointer dummy variable of type . The first of these is the passed-object dummy argument and shall be polymorphic if and only if is extensible. The use of PASS_OBJ is explained in 12.4.1.1." (8) Issue 37, missing constraints for procedure components. [40:43+] Insert "Constraint: The same shall not appear more than once in a given ." Move constraint at [40:21] to [40:43++]. Also, fix typo in the bnf and add a missing constraint. [41:25] Change "attr" to "attr-list". [41:31+] Insert "Constraint: The same shall not appear more than once in a given ." (9) Issue 38, comment from Van Snyder It was felt that there is no gain from restricting the initialisation expression to be a simple kind type parameter, and the current situation is more consistent with our existing SELECT CASE construct. [42:11-15] Delete. (10) Issue 39, SELECT KIND construct [13:21] after "" insert "; this includes case statements that occur within a but not those case statements that occur within a " (11) Issue 40, accessibility of type-bound procedures [46:24-25] Replace "If ... accessible." with "A type-bound procedure that is not private is accessible via any accessible object of the type. A private type-bound procedure is accessible only within the module containing the type definition." [47:1-13] Delete. (12) Issue 41, incorrect usage of NULL() intrinsic This did not conform to the passed specs, the following edits correct this. [41:36] Change "" to "". [41:39-42] Replace with "Constraint: The shall be the name of an accessible procedure that has an explicit interface. Constraint: The shall be specified unless the binding is overriding (4.5.3.2) an inherited (4.5.3.1) binding." Question: Should we prohibit when overriding? Answer: Yes, allowing it is error-prone and unnecessarily redundant. [41:41-42] Replace with: "Constraint: The shall be specified if and only if the binding is not overriding (4.5.3.2) an inherited (4.5.3.1) binding." Describe the no-argument use of NULL in this context. [109:27] Change "or" to "," [109:28] Before "." insert ", or designates a deferred type-bound procedure binding" [109:40+] Insert new line in table "in a | the type-bound procedure that would have been inherited" (13) Issue 42, overriding nonpure tbp with pure tbp Yes, this is deliberate. [52:36-42] Delete. (14) Issue 43, confusing examples [47:20+] Insert "... and in the of the same module:" [53:13+] Ditto [53:15] Change "POINT3D" to "POINT_3D". [53:23-28] Delete. (15) Issue 44, (default) accessibility of type-bound procedures [48:1] After "statement" insert "that is a " [48:9-11] Replace with "If a type definition contains a , only those type-bound procedures that are explicitly declared to be PUBLIC are accessible outside the module containing the definition; otherwise, only those type-bound procedures that are explicitly declared to be PRIVATE are inaccessible outside the module. Note 4.31a: The accessibility of a type-bound procedure is not affected by the presence or absence of a PRIVATE statement that is not a ." Alternative to edit at [48:1]: define a bnf term and use it. (Edits left to the readers' imagination). (16) Issue 45, reference to a type-bound procedure Accept proposed edit, viz [238:20] Replace with "The specific procedure denoted by is the one specified by a in the declaration of the dynamic type of , or inherited (4.5.3.1) into the declaration of the dynamic type of if none is declared (4.5.3.2)." (17) Issue 46, inappropriateness of "type-bound procedure" term. Noting that "dummy procedures" share exactly the same inappropriateness of terminology as "type-bound procedures", we do not believe there is any problem here, other than improving the explanation in the glossary. [46:27-39] Delete. [368:5-11] Replace with "<> (4.5.1.5): A procedure binding in a type definition. The procedure may be referenced by the via any object of that dynamic type." (18) Issue 47, PASS_OBJ [240:19-21] Replace sentence "In a procedure ... argument." with "In a procedure reference in which is a and the final is a procedure pointer with the PASS_OBJ attribute, the object of which the is a component is the actual argument that is associated with the passed-object dummy argument." (19) Unresolved issue 48, scope of a type-bound procedure name This only resolves the type-bound procedure part of issue 48, it does not resolve the component-name part of issue 48, which appears to be identical to issue 49. [322:38] Change "the PRIVATE statement" to "a PRIVATE statement that is a ." [323:1-5] Replace with "A binding name has the scope of a derived type definition. Outside the type definition, it may only appear as the in a procedure reference. If the binding name is not PRIVATE it is accessible in any scoping unit in which an object of the type is accessible. If the binding name is PRIVATE it is accessible only in the module." (20) Unresolved issue 49, accessibility of components etc. For type-bound procedure names this is resolved by the issue 48 resolution above. For component names this should be an F95 interp. (21) Unresolved issue 50, glossary entry for "binding" [360:4-11] Delete. The BNF definition of "binding" is completely adequate. (22) Unresolved issue 51, glossary entry for passed-object dummy argument [365:16-18] Replace with "<> (4.5.1): The dummy argument of a type-bound procedure or procedure pointer component that becomes associated with the object through which the procedure was invoked." COMMENT: A type-bound procedure or procedure pointer component can have dummy arguments even though they are not "regular" procedures, because they have an explicit interface. (23) Unresolved issue 52, glossary entry for type-bound procedure Resolved as part of issue 46 resolution.