CVS difference for ai12s/ai12-0058-1.txt

Differences between 1.6 and version 1.7
Log of other versions for file ai12s/ai12-0058-1.txt

--- ai12s/ai12-0058-1.txt	2015/10/08 23:21:52	1.6
+++ ai12s/ai12-0058-1.txt	2016/10/04 04:47:55	1.7
@@ -1,4 +1,8 @@
-!standard B.5                                   13-05-20    AI12-0058-1/02
+!standard B.5(19)                                16-10-02    AI12-0058-1/03
+!standard B.5(21)
+!standard B.5(31)
+!standard B.5(33)
+!standard 1.2(3/2)
 !class binding interpretation 13-05-20
 !status work item 13-01-22
 !status received 12-07-03
@@ -68,37 +72,14 @@
   type Complex_RK is new Complex_Types_RK.Complex;
 
 etc., should be more explicit, not a footnote.  Since Fortran standards
-since 1990 have required at least two kinds of real (single and doule
+since 1990 have required at least two kinds of real (single and double
 precision), and a kind of complex for each supported kind of real, it
 would be appropriate for Interfaces.Fortran to include a double
 precision complex type, and a double precision Imaginary subtype.
 
-Some important features of Fortran, e.g., assumed-shape dummy argument
-(formal parameter) arrays (corresponding to integer range <> for one
-dimension), optional arguments (parameters), and the distinction between
-pointer and allocatable variables in Fortran, are completely absent.  A
-recent ISO Technical Specification (29133), which will be incorporated
-into the next revision of the Fortran standard, specifies how these
-entities are described to C functions, by defining structs and functions
-to create, manipulate, and inquire descriptors and the objects they
-describe.
-
-Presumably, an Ada processor could use these descriptors and functions,
-without burdening the programmer, as is required in C, to exploit these
-facilities.  Even better would be for an Ada processor and a Fortran
-processor to conspire to use the same internal representation for these
-entities, so that Fortran programmers need not declare an Ada procedure
-to be referenced from Fortran, or a Fortran procedure to be referenced
-from Ada, to be C interoperable, which creates some headaches.
-
-Object-oriented programming features, modeled on Simula, were added to
-Fortran in the 2003 standard.  These include type extension,
-polymorphism, type-bound procedures, and overriding.  It may be
-desirable, yet difficult, to support this in annex B.5.
-
 Some of the terminology is wrong, with respect to the Fortran standard.
-For example, in the discussion of wkde character types, the Fortran Kind
-attribute is described as a "modifier."  This might have been necessary
+For example, in the discussion of wide character types, the Fortran Kind
+attribute is described as a "modifier." This might have been necessary
 to avoid confusion with the Ada term "attribute," but in this context it
 might introduce confusion instead.
 
@@ -111,8 +92,6 @@
    extensions are nonstandard.
 -- Remove permissions that implicitly recommend poor Fortran programming
    practices, or state explicitly that the practice is not recommended.
--- roperation with Fortran modules, subprograms
-   and derived types.
 
 1. Double precision complex
 
@@ -123,10 +102,12 @@
 definition of Interfaces.Fortran.
 
 Include a definition of double precision Imaginary, in the
-definition of Interfaces.Fortran.
-
-Include definitions of double precision "i" and "j", in the
-definition of Interfaces.Fortran.
+definition of Interfaces.Fortran. It would have been nice to include
+double precision i and j constants for double precision imaginary type
+in Interfaces.Fortran (since there are such constants for single
+precision imaginary), but since constants can't be overloaded, that is not
+possible. One will have to use Double_Precision_Complex_Types.i and so on
+instead.
 
 Include double precision complex in the list of Fortran-compatible types
 in paragraph 18.
@@ -183,15 +164,117 @@
   type Real_RK is digits RK;
 
 !wording
+
+Modify 1.2(3/2):
+
+ISO/IEC 1539-1:[2004]{2010}, Information technology
+- Programming languages - Fortran - Part 1: Base language.
+
+Modify AARM B.5(17.a):
+
+Ramification: The means by which the Complex type {and Double_Complex type}
+is provided in Interfaces.Fortran creates a dependence of
+Interfaces.Fortran on Numerics.Generic_Complex_Types (see G.1.1). This
+dependence is intentional and unavoidable, if the Fortran-compatible
+Complex type {and Double_Complex type} is to be useful in Ada code without
+duplicating facilities defined elsewhere.
+
+Modify B.5(19):
+
+The types Fortran_Integer, Real, Double_Precision, Logical, Complex,
+{Double_Complex, Character_Set,} and Fortran_Character are Fortran-compatible.
+
+Modify B.5(21):
+
+An implementation may add additional declarations to the Fortran interface
+packages. For example, [the Fortran interface package for an implementation
+of Fortran 77 (ANSI X3.9-1978) that defines types like Integer*n, Real*n,
+Logical*n, and Complex*n may contain the declarations of types named
+Integer_Star_n, Real_Star_n, Logical_Star_n, and Complex_Star_n. (This
+convention should not apply to Character*n, for which the Ada analog is the
+constrained array subtype Fortran_Character (1..n).) Similarly, the Fortran
+interface package for an implementation of Fortran 90 that provides multiple
+kinds of intrinsic types, e.g. Integer (Kind=n), Real (Kind=n), Logical
+(Kind=n), Complex (Kind=n), and Character (Kind=n), may contain the
+declarations of types with the recommended names Integer_Kind_n, Real_Kind_n,
+Logical_Kind_n, Complex_Kind_n, and Character_Kind_n]{declarations for the
+character types corresponding to Fortran character kinds 'ascii' and
+'iso_10646', which in turn correspond to ISO/IEC 646:1991, and
+to UCS-4 as specified in ISO/IEC 10646:2011 are permitted}.
+
+Modify AARM B.5(21.a):
+  {Reason: Fortran compilers are required to recognize 'ascii' and 'iso_10646'
+   as arguments to the SELECTED_CHAR_KIND intrinsic function, but are not
+   required to support those kinds.}
+
+   Discussion: Implementations may add auxiliary declarations as needed to
+   assist in the declarations of additional Fortran-compatible types.
+   For example, [if a double precision complex type is defined, then
+   Numerics.Generic_Complex_Types may be instantiated for the double precision
+   type. Similarly,] if a wide character type is defined to match a Fortran 90
+   wide character type (accessible in Fortran 90 with the Kind
+   [modifier]{attribute}), then an auxiliary character set may be declared to
+   serve as its component type."
+
+Add after B.5(31):
+
+     Precision: constant := 6;
+     type Standard_Deviation is digits Precision with Convention => Fortran;
+     Deviation : Standard_Deviation;
 
-** TBD.
+     type Atomic_Number is new Integer8 with Convention => Fortran;
 
+Add after B.5(33):
+
+   Deviation := ...;
+   Atomic_Number := ...;
+
 !discussion
 
-There are further aspects of interfacing with Fortran that ought perhaps
+This AI is mostly concerned with correcting obsolete references and practices
+mentioned in the Fortran Annex.
+
+There are further aspects of interfacing with Fortran that ought
 to be addressed as independent issues, probably resulting in more
-examples:
+examples:  e.g., assumed-shape dummy argument
+(formal parameter) arrays (corresponding to integer range <> for one
+dimension), optional arguments (parameters), and the distinction between
+pointer and allocatable variables in Fortran, are completely absent.  A
+recent ISO Technical Specification (29133), which will be incorporated
+into the next revision of the Fortran standard, specifies how these
+entities are described to C functions, by defining structs and functions
+to create, manipulate, and inquire descriptors and the objects they
+describe, similarly interoperation with Fortran modules which are similar
+to Ada packages are not mentioned.
+
+Presumably, an Ada processor could use these descriptors and functions,
+without burdening the programmer, as is required in C, to exploit these
+facilities.  Even better would be for an Ada processor and a Fortran
+processor to conspire to use the same internal representation for these
+entities, so that Fortran programmers need not declare an Ada procedure
+to be referenced from Fortran, or a Fortran procedure to be referenced
+from Ada, to be C interoperable, which creates some headaches.
+
+Since interoperability with these features are described in a Technical
+Specification that has not yet been incorporated into the Fortran standard, it
+would be premature to standardize interfaces to these features from Ada; Those
+concerns should be addressed as part of a separate AI, ideally after the next
+Fortran standard is published.
+
+Object-oriented programming features, modeled on Simula, were added to
+Fortran in the 2003 standard.  These include type extension,
+polymorphism, type-bound procedures, and overriding.  It may be
+desirable, yet difficult, to support this in annex B.5.
+
+Due to this perceived difficulty in designing and describing Ada interfaces to
+these features, the addition of interfaces to object oriented
+features of Fortran should also be split off as a separate AI, as the decision
+to progress those features should be weighed independently from the main goals
+of this AI, which is mostly to update the existing content of the Fortran
+Annex.
 
+Other possible interfaces to Fortran not addressed by this AI include;
+
 -- Use of the Convention aspect for record types to interoperate with
    Fortran derived types.  Additional sub-issues, for which the
    correspondence between Fortran and Ada (if any) ought to be
@@ -203,10 +286,7 @@
       can be specified by evaluation of expressions during execution;
    .. Fortran provides for type-bound procedures.
 
--- mport and Export aspects for Ada subprograms
-   to be referenced from Fortran, and for Fortran subprograms to be
-   referenced from Ada.  An important sub-issue is the correspondence to
-   Fortran optional arguments.
+-- The correspondence to Fortran optional arguments.
 
 -- Use of the External_Name aspect of Ada subprograms, to allow access
    from Fortran, should be illustrated.
@@ -794,5 +874,49 @@
 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.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Sunday, October 2, 2016  12:54 AM
+
+Here is my first attempt to update the Fortran annex. [This is version /03
+of the AI.]
+
+I just updated things that were obviously out of data, or incorrect, as
+suggested by the AI. However, I decided to leave out new interfaces to Fortran,
+with the thought that it would be better to cover those in a separate AI.
+
+For example, the AI mentions that there exists an ISO Technical Specification
+ISO TS 29133:2012, that defines how C can inter-operate with Fortran language
+features. This TS however is not yet incorporated into the Fortran standard, so
+it would appear to be premature to standardize Ada interfaces to Fortran using
+this information, and it would be better to wait for the next revision of the
+Fortran standard for this.
+
+Similarly, interfacing to Fortran object oriented types could be possible, but
+the level of difficulty to tackle this seems considerably higher than the rest
+of the updates in the AI, so the AI recommends that adding interfacing to OO
+Fortran features should probably be split off into a separate AI.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, October 3, 2016  11:16 PM
+
+> Here is my first attempt to update the Fortran annex.
+
+You forgot to update the summary; it says "** Summary of actual changes.",
+which doesn't appear to be a real summary. ;-)
+
+> I just updated things that were obviously out of data, or incorrect, 
+> as suggested by the AI. However, I decided to leave out new interfaces 
+> to Fortran, with the thought that it would be better to cover those in 
+> a separate AI.
+
+Yes, that makes sense. Get the easier issues dealt with first.
+
+I updated the format of the wording (it resembles some awful formatting from
+the parallel AI, which is too big to fix -- but let's not persist that format).
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent