CVS difference for ai12s/ai12-0058-1.txt
--- ai12s/ai12-0058-1.txt 2013/06/11 01:04:36 1.5
+++ ai12s/ai12-0058-1.txt 2015/10/08 23:21:52 1.6
@@ -598,3 +598,201 @@
friendly local Fortran expert tells me that you're quite correct!
+From: Tucker Taft
+Sent: Friday, September 18, 2015 10:04 PM
+Here is a proposal from Van Snyder about how to update the Fortran annex.
+I haven't evaluated it myself yet.
+Proposed changes to Subclause B.5
+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 appears not to be a Double_Precision_Complex_Types package in Ada
+2012. If there will be one in the next revision, add
+ type Double_Complex is new Double_Precision_Complex_Types.Complex
+after paragraph 9, and add that and "double precision complex" to the
+above paragraph. I don't think it's necessary to have double precision
+versions of "Imaginary", "i", and "j".
+Fortran 2008 requires processors to support ASCII and ISO 10646
+character kinds, in addition to whatever their default is. I don't know
+how to connect this to Ada.
+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. For that purpose, however, it's
+probably sufficient for users to interface their Fortran procedure to Ada
+using Fortran's C interoperability features.
+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 it is 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
+A Fortran allocatable object could be an actual argument that
+corresponds 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.
+"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
+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. If the Ada formal parameter is described
+as an explicit-shape or assumed-size array, it might result in
+copy-in/copy-out argument passing if the Fortran actual argument is not
+contiguous. Some Fortran compilers always use copy-in/copy-out without
+bothering to do a runtime check whether the actual argument is
+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 <n>, whether those values correspond to
+Fortran kind type parameters with the same values depends upon the
+(The notation <n> 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 184.108.40.206 of the
+Fortran 2008 standard. Without the SEQUENCE attribute, the memory
+layout of components is processor dependent. 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
+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.
+From: Randy Brukardt
+Sent: Thursday, October 1, 2015 10:06 PM
+You do remember that you volunteered to help him turn this into RM wording,
+right??? And that it's part of your homework for the upcoming meeting??? We
+need this to progress to something we can finish someday, not just endless
+proposals without RM-level details.
Questions? Ask the ACAA Technical Agent