J3/02-188R1 To: J3 From: John Reid modified by interop/Meadows Subject: Interoperability edits Date: 14 May 2002 This paper has been substantially modified by /interop. Subgroup's comments are enclosed in {}. Modified edits have *ALTERED* before them. 28:2+. Add 'END ENUM' to the list. *ALTERED* 43:20-21. Change 'a C struct type with which an entity of the derived type is interoperable (15.2.3)' to 'a C struct type with which the derived type is interoperable (15.2.3)'. [Section 4 is about types and 15.2.3 is about interoperability of types.] { There may be more tha one C struct type with which the derived type is interoperable } 64:23. Set 'enumerator' in italics. Change 'for' to 'in' 64:29-65:1. Change 'an entity of type integer with that kind is interoperable (15.2) with an entity of the corresponding C enumeration type' to 'a type integer with that kind is interoperable (15.2.1) with the corresponding C enumeration type'. 71:32. Change 'subprogram or interface body' to 'procedure'. [We need to allow for ENTRY. There is no need to mention 'interface body' explicitly. This is simply one mechanism for giving the attribute to a procedure. For example, 12.4.1 makes no mention of interface blocks, but a procedure written in another language may use keyword arguments as long as it has an interface block. ] *ALTERED* 77:11. Delete (15.2.7) after '.' { Subgroup believes that the standard already makes it clear that there need not be any interoperable entity } *ALTERED* 87:6-11 No edits required. { 02/188 comments are wrong. BIND statement is available for procedures and derived types. } 277:15. Change 'whose interface' to 'that'. [The BIND attribute is a characteristic of a procedure, see 12.2. It may, of course, be specified by an interface block.] *ALTERED* 282:22-23. No edits required. { There is no requirement that there be such a C function. Already specified. } *ALTERED* 381:14-16 Change ', C_NULL_CHAR, ... C_NULL_PTR.' to 'and the first column of Table 15.2, the procedures specified in 15.1.2, and C_PTR and C_NULL_PTR. 383:1. Change 'target' to 'TARGET'. *ALTERED* 383:2. No edits needed. { 'has' is just fine } 383:8. Change 'object' to 'entity'. 384:7-9. Delete the J3 internal note and replace lines 7-9 by The following subclauses define the conditions under which a Fortran entity is interoperable. If a Fortran entity is interoperable, an equivalent entity may be defined by means of C and the Fortran entity is said to be interoperable with the C entity. There does not have to be such an interoperating C entity. *ALTERED* 384:20+. Add paragraph: A combination of intrinsic type and type parameters is <> if it is interoperable with a C type. {Subgroup found the grammar of the original edit to be difficult. This seems to be slightly better. } *ALTERED* 386:4. Change to 15.2.3 Interoperability of derived types and C struct types { Kept the title change, did not see the need for the other edits } *ALTERED* 387:1-4. Change to 15.2.4 Interoperability of scalar variables A scalar Fortran variable is <> if its type and type parameters are interoperable, and it has neither the pointer nor the allocatable attribute. An interoperable scalar Fortran variable is interoperable with a scalar C entity if their types and type parameters are interoperable. { Deleted "it is not polymorphic, ", that is implied by the remaining text, and changed "types" to "type" } *ALTERED* 387:5. Change to 15.2.5 Interoperability of array variables An array Fortran variable is <> if its type and type parameters are interoperable, it is of explicit shape or assumed size. {Same as above} *ALTERED* 388:1. Change to 15.2.6 Interoperability of procedures and procedure interfaces { Kept the title change. The rest of the edits are not needed. Paper 198r1 fixes unresolved issue #347 } 389:7. Delete 'procedure'. 389:9+. In NOTE 15.20, add INTERFACE END INTERFACE around the Fortran code. 390:0. Interchange the two USE statements in NOTE 15.21. *ALTERED* 390:7. No edits needed {with all of the above we need this} *ALTERED* 391:13-392:1 Replace by 'The procedure may be defined by means other than Fortran, or may be defined by means of a Fortran subprogram that has a <> in its <>, <>, or <>. { Subgroup intends that different ENTRYs may have different BINDs. The rest is just cleanup. } 392:23+, NOTE 15.23. After the SUBROUTINE statement, add .. and after the present USE statement, add .. [The dots indicate that these procedures do something.] 395:18. After 'external procedures,' add 'procedure binding labels,'. *ALTERED* 412:46-49. No edits required. {Subgroup believes that association is well-defined for variables of type C_PTR and that no new form of association is introduced}. 421:7+. Add <> (15.2). The property of a Fortran entity that ensures that an equivalent entity may be defined by means of C.