J3/15-236 To: J3 Members From: Van Snyder Subject: Ada liaison Date: 2015 October 07 I sent the following liaison report to Dr. Joyce L. Tokar, the convenor of WG9 (Ada) at her request. ======================================================================== To: WG9 From: Van Snyder Date: 2015 October 07 Subject: Fortran liaison report The technical content of the next revision of Fortran, to be known informally as Fortran 2015, was decided at the SC22/WG5 meeting in London during 3-7 August 2015. The details are in WG5 paper N2082, which in turn refers to other WG5 papers, and PL22.3 (formerly J3) papers. WG5 papers are available from http://www.nag.co.uk/sc22wg5/docs.html. J3 papers are available from http://j3-fortran.org/doc/year. J3 papers' file names begin with a year and a hyphen. The WG5 paper for ISO/IEC TS 18508 is N2027. The WG5 paper for ISO/IEC TS 29113 is N1942. The next three meetings of PL22.3 (12-16 Oct, 8-12 Feb, 6-10 Jun) will be devoted to proofreading the draft of ISO/IEC 1539-1. We hope to forward it to ISO for publication in 2016. Suggestions for a revision of subclause B.5 of ISO/IEC 8652:2012, concerning Fortran interoperability, have been forwarded to Tucker Taft. ======================================================================== The suggestions I sent to Tucker Taft are ======================================================================== To: ISO WG9 From: Van Snyder Subject: Proposed changes to Subclause B.5 Date: 2015 October 07 Replace paragraph 18: "Fortran intrinsic types are characterized by a parameter called a kind type parameter. If a kind type parameter is not specified, a processor-dependent default is assumed. The types Fortran_Integer, Real, Double_Precision, Logical, Complex, and Fortran_Character are compatible with the Fortran intrinsic types and kinds default integer, default real, double precision, default logical, default complex, and default character, respectively." There is no mention of the Fortran ALLOCATABLE or POINTER attributes. Unlike C pointers, Fortran pointers are strongly type constrained, unless they are unlimited polymorphic pointers. Also unlike C pointers, Fortran pointers are "fat" in that if they are array pointers they contain bounds information. The target of an array pointer might be a non-contiguous section of an array. For example, consider an array A with dimensions (10,10), and a two-dimensional pointer P. A pointer assignment statement of the form "P => A(3:7,4:6)" would associate the noncontiguous section of A consisting of rows 3-7 and columns 4-6 with the pointer P, which thereby has runtime bounds of (1:5,1:3). Should the Ada standard contemplate interoperating with Fortran pointers? Fortran also defines a type C_PTR this is simply a C pointer. Should the Ada standard contemplate interoperating with Fortran objects of type C_PTR? If so, this should be mentioned in a paragraph after paragraph 19. I don't know what to recommend. Fortran allocatable objects are much more strongly constrained than pointers. They can be allocated and deallocated, but they are always contiguous and are automatically deallocated when they go out of dynamic scope. As with Fortran pointers, descriptors of allocatable objects that are arrays contain bounds and stride information. I don't know whether Ada has a type whose objects could be actual parameters that correspond to Fortran dummy arguments with the ALLOCATABLE attribute, unless the Ada processor is willing to conspire with a companion Fortran processor to use the same storage allocator. If the Ada standard should contemplate this interoperability, it should be mentioned in a paragraph after paragraph 19. I don't know what to recommend. An alternative to addressing these interoperability problems is to mention Fortran's support for C interoperability, and to recommend that an Ada program pretend that it is interoperating with C procedures when it is in fact interoperating with Fortran procedures that are C interoperable. Something like "It is possible for objects of other Ada types to be passed between Ada and Fortran programs. In a reference from an Ada program to a Fortran subprogram, the Ada actual parameters shall be compatible with C (B.3), the Fortran subprogram shall be described to the Ada program as if it were a C function, and the Fortran subprogram shall be declared within the Fortran program to have the BIND(C) attribute. In a reference from a Fortran program to an Ada subprogram, the Ada subprogram and its formal parameters shall be compatible with C (B.3) and the Ada subprogram shall be described to the Fortran program as if it were a C function. Refer to Clause 15 of the Fortran International Standard (ISO/IEC 1539-1)." A Fortran allocatable object could correspond to an Ada formal parameter, provided the Fortran description of the Ada subprogram's interface does not specify the parameter to be allocatable, and the Ada subprogram's formal parameter is not of a dynamically allocatable type. This probably doesn't need to be mentioned. It ought to just work. Fortran has polymorphic objects, but does not contemplate that these interoperate with C. Fortran's object-oriented system is based upon Simula's. The Fortran standard does not contemplate that polymorphic objects can interoperate with C++ polymorphic objects. It probably doesn't make sense for the Ada standard to contemplate that objects of tagged record types could interoperate with Fortran polymorphic objects. This should be mentioned in a paragraph after paragraph 19. Something like "There is no provision to interface objects of tagged record types with Fortran polymorphic objects." Components in Fortran derived types can have the POINTER or ALLOCATABLE attribute. If the Ada standard does not contemplate interoperating with objects with these attributes, it should be mentioned in a paragraph after paragraph 19 that there are no Ada record types whose objects can interoperate with Fortran derived-type objects that have components with these attributes. Something like "There are no Ada record types whose objects can interface with Fortran derived-type objects that have components with the ALLOCATABLE or POINTER attributes." Fortran dummy arguments can be of assumed shape, which means that the actual argument corresponding to an assumed-shape dummy argument is a descriptor that provides bound and stride information. The Fortran standard now contemplates that assumed-shape dummy arguments can interoperate with C parameters, in either direction. C macros to produce descriptors are described in Clause 15 of the Fortran standard. I don't know what to recommend here. If it is non contemplated that the Ada standard should support this interoperability, it might be mentioned that an Ada actual parameter cannot correspond to an assumed-shape Fortran dummy argument, and in a reference from a Fortran program to an Ada subprogram, the Ada formal parameter shall not be described as a Fortran assumed-shape array. This would result in copy-in/copy-out argument passing if the Fortran actual argument is not contiguous. Fortran dummy arguments can have the OPTIONAL attribute. I don't know whether Ada has an equivalent concept. Within paragraph 21, in the second line, insert "nonstandard" between "defines" and "types". At the end of paragraph 21, insert a sentence "The Fortran standard does not specify the values of kind type parameters. In particular, the value of a kind type parameter does not necessarily specify the number of bytes occupied by objects of that kind. Therefore if a Fortran interface package contains declarations of types with integer values for , whether those values correspond to Fortran kind type parameters with the same values depends upon the Fortran processor." (The notation means "n" in italic font.) I don't know what to do about paragraph 25. Fortran provides two attributes for derived types that affect the layout of components of objects of types with those attributes. The SEQUENCE attribute requires components to be laid out in the order they appear in the type definition, with no padding between them. See subclause 4.5.2.3 of the Fortran 2008 standard. The BIND(C) attribute requires all the components to be C interoperable, and that they be laid out as a companion C processor would lay them out. The Fortran standard does not specify what this means. The definition of a "companion" processor is processor dependent. Should an Ada actual parameter that is a data object of a Fortran compatible record type correspond to a Fortran dummy argument that has the SEQUENCE or BIND(C) attribute, or is the Ada processor expected to know its companion Fortran processor's derived-type component layout rules? I don't know what to recommend. In paragraph 26, replace "Fortran procedure" with "Fortran procedure's dummy procedure". Fortran has procedure pointers, which can be dummy procedures or components of objects of derived type. I don't know whether an access-to-subprogram object can have a convention denotation, and if so whether that ought to be mentioned in connection with associating an access-to-subprogram object with a Fortran procedure pointer. The Fortran standard does not contemplate that Fortran procedure pointers should interoperate with C function pointers. Rather, Fortran provides a C_FUNPTR type, and procedures to copy between that and Fortran procedure pointers. If the Ada standard does not contemplate a Fortran convention for access-to-subprogram objects, this might also be swept under the C interface rug. Otherwise, at the end of paragraph 26, add a sentence "An Ada parameter of access-to-subprogram type and Fortran convention may correspond to a Fortran argument that is a procedure pointer." I assume Ada records can have access-to-subprogram components, in which case also change the edit recommended above concerning Fortran derived-type objects with ALLOCATABLE or POINTER components by inserting "data" before "components". Fortran types can have type-bound procedures. I see no prospect for objects of these types interoperating with Ada. Fortran types can have finalization subroutines. I see no prospect for objects of these types interoperating with Ada. I don't know whether this deserves mention.