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
+(ISO/IEC 1539-1)."
+
+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. 
+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.  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
+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 <n>, whether those values correspond to
+Fortran kind type parameters with the same values depends upon the
+Fortran processor."
+
+(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 4.5.2.3 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
+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.
+
+****************************************************************
+
+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.
+
+****************************************************************