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

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

--- ai12s/ai12-0058-1.txt	2013/02/01 06:25:44	1.2
+++ ai12s/ai12-0058-1.txt	2013/06/10 23:09:13	1.3
@@ -1,4 +1,4 @@
-!standard B.5                                   13-01-22    AI12-0058-1/00
+!standard B.5                                   13-02-20    AI12-0058-1/01
 !class Amendment 13-01-22
 !status work item 13-01-22
 !status received 12-07-03
@@ -7,7 +7,12 @@
 !subject The Fortran Annex needs updating to support Fortran 2008
-** TBD.
+Annex B.5 Interfacing with Fortran
+-- is out of date and incomplete with respect to Fortran 2008,
+-- offers implementation permissions to interface with declarations that
+   are not part of any Fortran standard, and
+-- offers implementation permissions based upon unsound Fortran
+   programming practice.
@@ -93,7 +98,83 @@
-** TBD.
+-- Include support in Interfaces.Fortran for all intrinsic types and kinds
+   required by the Fortran standard.
+-- Remove permissions that correspond to nonstandard extensions to the
+   1966 Fortran standard, or reword them to specify explicitly that the
+   extensions are nonstandard.
+-- Remove permissions that implicitly recommend poor Fortran programming
+   practices, or state explicitly that the practice is not recommended.
+-- Include examples of interoperation with Fortran modules, subprograms
+   and derived types.
+1. Double precision complex
+Include an instantiation of Ada.Numerics.Generic_Complex_Types for
+double precision, in the definition of Interfaces.Fortran.
+Include a definition of a double precision complex type, in the
+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.
+Include double precision complex in the list of Fortran-compatible types
+in paragraph 18.
+2. Additional character kinds
+The Fortran standard defines a default character set.  It should be
+remarked that the type Character_Set is compatible with the Fortran
+default character kind.
+The Fortran standard requires that the SELECTED_CHAR_KIND intrinsic
+function accept the argument values 'ascii' and 'iso_10646' (without
+regard to case), and return positive values if the processor supports
+those kinds of characters.  The kind 'ascii' corresponds to ISO/IEC
+646:1991.  The kind 'iso_10646' corresponds to UCS-4 as specified in
+ISO/IEC 10646.
+Since 'ascii' and 'iso_10646' kinds are defined by the Fortran standard,
+but support for them is not required, they should be mentioned under
+"Implementation Permissions."
+3. Inappropriate material in "Implementation Permissions"
+The type specifications Integer*n etc. have never been part of any
+Fortran standard, although they were provided as an extension by many
+processors that otherwise conformed to the 1966 standard.
+If any mention of them is to be retained in paragraph 21 of Annex B.5,
+it should be made clear that these were nonstandard extensions, and the
+reference to Fortran 77 should be removed.
+Using constants as kind type parameter values in Fortran 90 should be
+avoided, because the values are processor dependent.  The declarations
+Integer(kind=4) and Integer(kind=8) might mean four-byte and eight-byte
+integers on one processor, while a different processor (or the same
+processor with different command-line options) might use Integer(kind=1)
+and Integer(kind=2) for the same objects.  If this material is to be
+retained, it should be made clear that using constants as kind type
+parameter values is not recommended.
+It would be better to provide, under "Examples," illustrations of the
+correspondence between Ada types and Fortran types and kinds, at least
+for Integer and Real.  For example, a Fortran type and kind for Real
+with six digits of precision and unspecified range, would be declared in
+Fortran using
+  integer, parameter :: RK = selected_real_kind(p=6)
+  real(rk) :: X
+An Ada object expected to interface with this object would be declared
+  RK: constant := 6;
+  type Real_RK is digits RK;
@@ -101,16 +182,56 @@
-Hopefully a Fortran expert can make specific proposals on this topic,
-because most of the ARG has only a passing familarity with Fortran.
+There are further aspects of interfacing with Fortran that ought perhaps
+to be addressed as independent issues, probably resulting in more
+-- 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
+   illustrated, include
+   .. Fortran allows for type extension;
+   .. Fortran allows to parameterize derived types, with parameter
+      values specified for objects of the type.  "Kind" parameters
+      are required to have constant values, while "length" parameters
+      can be specified by evaluation of expressions during execution;
+   .. Fortran provides for type-bound procedures.
+-- Use of the Convention, Import 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.
+-- Use of the External_Name aspect of Ada subprograms, to allow access
+   from Fortran, should be illustrated.
+-- Use of the Convention aspect for access-to-subprogram objects to
+   interoperate with Fortran procedure pointers should be illustrated.
+-- Fortran has a "module" system that roughly corresponds to the Ada
+   package system, without generic parameters.  The use of the
+   Convention aspect of a package spec to declare the availability of
+   Fortran module entities (at least subprograms) to Ada programs should
+   be illustrated.
+-- Fortran has data pointers that are "fat," that is, that include array
+   bounds and strides, not simply addresses, such as C pointers.  The
+   correspondence of Ada access types and Fortran pointers, if there is
+   any, should be illustrated.
+It is not expected that any of these facilities will require additional
+ASIS support.
 !ACATS test
+Hopefully, Van or some other Fortran expert can provide some ACATS C-Tests
+for these features. (There is little ACATS testing of the Fortran interface
+in the current ACATS.)
@@ -208,7 +329,7 @@
 From: Tucker Taft
 Sent: Friday, November  2, 2012  9:46 AM
-> Does WG9 have any interest in a (formal or informal) liaison with the 
+> Does WG9 have any interest in a (formal or informal) liaison with the
 > Fortran committees (WG5, or ANSI/INCITS/PL22.3) to improve Annex B.5?
 Yes, I am sure WG9 would be interested in more Fortran expertise.
@@ -229,5 +350,242 @@
 Ada-Comment list, in terms of specific changes.  We could then invite you to
 one of the ARG meetings, if that would be appropriate, to have a longer
 discussion of these issues.
+From: Tucker Taft
+Sent: Wednesday, February 27, 2013  4:46 PM
+    I have CC'ed the Ada Rapporteur Group.
+It is great you can help with Fortran interoperability.
+All of the Ada Issues pertaining to the Ada 2012 standard are available at:
+If you want to see *all* of the AIs ever written, go to:
+and then click on the version of the standard of interest, and then click on the "Ada Issues Database Index" link for that version.
+Once you click on an individual AI, it will actually take you to the configuration management system.  You will generally want to choose the latest version of the AI.
+I have attached one AI as an example.
+On 2/27/13 5:05 PM, Van Snyder wrote:
+> Tucker:
+> I've gotten an official liaison charge from the US TAG for Fortran,
+> INCITS/PL22.3, to serve as liaison with ISO/IEC JTC1/SC22/WG9.  It's
+> attached.
+> My primary interest is subclause B.5, barely more than two pages,
+> concerning Fortran interoperability.  I don't feel qualified to offer
+> opinions concerning other aspects of the Ada standard.
+> It is almost certain that I cannot attend the meeting in Berlin.
+> There is a remote chance I can come to the meeting in Pittsburgh, or
+> at least a day of it.  Please add my address to the mailing list for
+> the announcement.
+> Can you send me an example of an "Ada Issue" paper?  I can prepare
+> suggestions for changes to the Fortran interoperability annex B.5 in
+> the same format.  Perhaps the necessary changes can be handled
+> entirely by correspondence, without the need for me to attend any meetings.
+> Best regards,
+> Van Snyder
+> On Wed, 2012-12-19 at 20:45 -0500, Tucker Taft wrote:
+>> On 12/19/12 7:45 PM, Van Snyder wrote:
+>>> On Fri, 2012-12-07 at 09:26 -0500, Tucker Taft wrote:
+>>>> Hi Van,
+>>>>        Sorry to just forward you to Joyce, when in fact she had forward you to me!
+>>>> Yes, we would love to get more input on Fortran interfacing.  The
+>>>> Ada Rapporteur Group (ARG) does the "real" work on the Ada
+>>>> standard.  The most useful input would be to send a more complete
+>>>> proposal to the Ada-Comment list, in terms of specific changes.  We
+>>>> could then invite you to one of the ARG meetings, if that would be appropriate, to have a longer discussion of these issues.
+>>> Tucker:
+>>> Sorry to take so long to respond.
+>>> Where does ARG meet, and how frequently?
+>> It meets twice a year currently, once in Europe (in conjunction with
+>> AdaEurope) and once in the US (in conjunction with SIGAda's annual
+>> conference, now dubbed "HILT").
+>> The next ARG meeting is in Berlin in June 2013, and then in
+>> Pittsburgh in October or November 2013.
+>>> I already go to three Fortran meetings per year, and one or two math
+>>> meetings.  I might have trouble getting funding for another meeting,
+>>> especially if it's not in the United States.  After the GAO party
+>>> debacle last year, I had travel to Canada canceled!
+>>> Proposals for changes to the Fortran standard take the form of a
+>>> document specifying the basic functionality, the reason for the
+>>> change, and a detailed specification.  If the proposal gets
+>>> accepted, further work starts with polishing the specifications,
+>>> then developing syntax, then finally edits.  I don't think the
+>>> "syntax" stage would be relevant to what I think is needed in the
+>>> Fortran interoperability annex, B.5, in the Ada standard.  Would ARG
+>>> prefer to pursue changes to B.5 in proposal ... specifications ...
+>>> edits stages, or should I just send edits to you, or the Ada-comment list?
+>> We have a format for what we call an "Ada Issue" (AI), which
+>> includes, generally, the following sections:
+>>     - summary (short summary of proposal)
+>>     - problem (problem the proposal is intended to fix)
+>>     - proposal (high level description of proposal)
+>>     - wording (actual changes to the wording)
+>>     - discussion (justification for proposal; rejected
+>>         alternatives, etc.)
+>>     - examples (examples of use of the new capability)
+>>     - appendix (copies of e-mails commenting on the problem
+>>         or the proposal)
+>>> Fortran is developed by ANSI/INCITS/PL22.3, according to
+>>> specifications set by WG5.  PL22.3 is called a "development body."
+>>> Is that how ARG is related to WG9?
+>> Yes, sounds like.
+>>> There is a remote chance of improving prospects for funding if I am
+>>> appointed as formal liaison between WG5 and WG9, or ARG and PL22.3,
+>>> or both.  Would it be helpful if I were to ask PL22.3 for this
+>>> appointment, from their end, at the upcoming meeting in February?
+>> Yes, that would be great.
+>>> Best regards,
+>>> Van
+>> Take care, and happy holidays,
+>> -Tuck
+From: Randy Brukardt
+Sent: Thursday, February 28, 2013  9:42 PM
+> I've gotten an official liaison charge from the US TAG for Fortran,
+> INCITS/PL22.3, to serve as liaison with ISO/IEC JTC1/SC22/WG9.  It's
+> attached.
+Welcome aboard. To everyone else: Van has been added to the ARG mailing list. As
+always, it's preferred to have technical discussions here or on Ada-Comment, so
+that they are "on the record" and preserved in the AI(s) for future amusement.
+> My primary interest is subclause B.5, barely more than two pages,
+> concerning Fortran interoperability.  I don't feel qualified to offer
+> opinions concerning other aspects of the Ada standard.
+That doesn't always stop us from commenting on topics that we don't know that
+much about. :-) Feel free to comment on anything, because sometimes a fresh look
+at a topic is just what we need.
+<Huge technical discussion elided>
+Van sent me privately a long and detailed list of possible areas to improve.
+I have suggested that he distill it down to a bunch of bullets so that we can
+see the big picture (that's hard to do in a couple of pages of details) and use
+that as a starting point for discussion.
+P.S. The (mostly empty) AI for this topic is AI12-0058-1. We'll probably split
+it into several if there are topics of different priority/difficulty.
+From: Van Snyder
+Sent: Monday, May 20, 2013  4:08 PM
+The US ANSI Fortran committee has appointed me as their liaison to ARG and WG9,
+a liaison that I hope will be accepted by the Ada committees.
+Our only interest at this time is that there are a few minor mistakes concerning
+Fortran in ISO/IEC 8652:2012.
+In summary:
+1. The citation for the Fortran standard in subclause 1.2,
+   paragraph 3/2, should be updated to 1539-1:2010.  Another
+   revision of the Fortran standard is to be submitted to ISO for
+   ballot and publication in 2015.  If the next revision of the
+   Ada standard appears after the next Fortran standard, care
+   should be taken to cite the version current at that time.
+2. Remove permission in subclause B.5 paragraph 21 for a
+   Fortran interface package to include declarations of types
+   Integer_Star_n etc.  The corresponding Fortran declarations
+   cited in that paragraph (e.g. Real*n) were never part of any
+   Fortran standard, and in particular were not included in
+   Fortran 77 (ANSI X3.9-1978), which is cited in that paragraph.
+3. Remove permission in subclause B.5 paragraph 21 to use
+   Integer_Kind_n etc. to correspond to Fortran declarations
+   Integer(Kind=n), because using constant kind type parameters in
+   Fortran is a non-portable practice that ought not to be used.
+   The recommended way to request a kind for, e.g., a real type,
+   in Fortran is to specify the precision (and optionally the
+   range) using the SELECTED_REAL_KIND intrinsic function.  E.g.,
+   for six digits of precision and unspecified range use
+     integer, parameter :: RK = selected_real_kind(p=6)
+     real(rk) :: X
+   In Ada this might correspond to
+     RK: constant := 6;
+     type Real_RK is digits RK with Convention => Fortran;
+     X: Real_RK;
+   If included, this kind of material would appear in the
+   "Examples" subclause.
+4. Within the Interfaces.Fortran package, declare an Ada type
+   corresponding to double precision complex in Fortran.  A
+   Fortran processor is required to provide a complex kind for
+   each provided real kind, and double precision real kind is
+   required.
+5. Allow an implementation to declare 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.  This should be a
+   permission, not a requirement.  Fortran processors 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.
+There are also opportunities for Ada to interface with facilities of Fortran,
+such as module procedures (Fortran modules are similar to Ada packages),
+optional procedure arguments, and type extension.
+More details are in the attachment, which I hope is roughly in the format of an
+AI paper. [This is version /01 of the AI - Editor.]
+If there is sentiment to pursue these revisions, I can assist with development
+of editorial changes.  It is very unlikely that I will secure funding to travel
+to Ada committee meetings, especially the upcoming meeting in Berlin.
+For reference, the DIS for Fortran 2008 (ISO/IEC 1539-1:2010) is available as
+  There are no textual differences.
+The mechanical difference between this and the balloted version,
+, is that ligatures such as fi,
+fl... are set in 12-007 using kerning instead of special characters.  The result
+is that the Acrobat reader can find words that contain them.
+From: Jeff Cousins
+Sent: Wednesday, May 22, 2013  10:03 AM
+Thanks for that Van.  It's a long time since I wrote any Fortran, but my
+friendly local Fortran expert tells me that you're quite correct!

Questions? Ask the ACAA Technical Agent