Version 1.7 of ai12s/ai12-0058-1.txt

Unformatted version of ai12s/ai12-0058-1.txt version 1.7
Other versions for file ai12s/ai12-0058-1.txt

!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
!priority Medium
!difficulty Medium
!subject The Fortran Annex needs updating to support Fortran 2008
!summary
** Summary of actual changes.
!question
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.
Should this be fixed? (Yes.)
!recommendation
Annex B.5, describing Interfaces.Fortran, includes some inappropriate advice, could be more complete, and is obsolete with respect to the current (2008) Fortran standard.
The declarations "real*n" etc., recommended for use with Fortran 77, were never part of any standard. The implementation-dependent types Real_Kind_n etc., where n is an integer, recommended for use with Fortran 90, are not as useful as they could be, because the value of n depends upon both the companion Fortran processor, and the options used to compile the Fortran program unit with which the types are hoped to interoperate.
Fortran provides facilities by which a program can inquire the kind type parameter value using the desired precision or range of a floating-point number, or the kind type parameter value of an object, using e.g. kind(1.0d0). If an Ada programmer sees declarations in a Fortran program unit of the form
integer, parameter :: RK = selected_real_kind(p=6,r=30) ! Precision: at least 6 digits; exponent range: at least 30 real(rk) :: X
the advice to use Real_Kind_n is not useful. It is not uncommon for these declarations to be in different program units. A Fortran program frequently has a module where the kind type parameters to be used throughout the program are declared, and those parameters are then used, by access to that module, throughout the program. The Ada programmer ought to be advised to define a type using
RK: constant := 6; type Real_RK is digits RK;
The Fortran standard has, since 1990, required that a processor provide a kind of complex corresponding to each kind of real, with the kind type parameter specified in the same way as for real, and having the same value as real objects of the same kind as the real and imaginary parts of the complex object have. Annex B.5 supports only single precision complex. The discussion in B.5(21.a) that reminds a programmer that it is possible to instantiate a complex type corresponding to a Fortran complex type and kind using, e.g.,
package Complex_Types_RK is new Ada.Numeric.Generic_Complex_Types ( Real_RK ); 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 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 of the terminology is wrong, with respect to the Fortran standard. 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.
!proposal
-- 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.
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. 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.
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 using
RK: constant := 6; 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 Integern, Realn, Logicaln, and Complexn 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;
type Atomic_Number is new Integer8 with Convention => Fortran;
Add after B.5(33):
Deviation := ...; Atomic_Number := ...;
!discussion
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: 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 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.
-- 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.
!example
!ASIS
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.)
!appendix

!topic Fortran 2008 interoperability
!reference ISO/IEC_8652:201z_Ada_ARM (Submission Draft [Draft 18]) B.5
!from Van Snyder 2012-11-01
!keywords Fortran interoperability
!discussion

Annex B.5, describing Interfaces.Fortran, includes some inappropriate
advice, could be more complete, and is obsolete with respect to the
current (2008) Fortran standard.

The declarations "real*n" etc., recommended for use with Fortran 77,
were never part of any standard.  The implementation-dependent types
Real_Kind_n etc., where n is an integer, recommended for use with
Fortran 90, are not as useful as they could be, because the value of n
depends upon both the companion Fortran processor, and the options used
to compile the Fortran program unit with which the types are hoped to
interoperate.

Fortran provides facilities by which a program can inquire the kind type
parameter value using the desired precision or range of a floating-point
number, or the kind type parameter value of an object, using e.g.
kind(1.0d0).  If an Ada programmer sees declarations in a Fortran
program unit of the form

  integer, parameter :: RK = selected_real_kind(p=6,r=30)
  ! Precision: at least 6 digits; exponent range: at least 30
  real(rk) :: X

the advice to use Real_Kind_n is not useful.  It is not uncommon for
these declarations to be in different program units.  A Fortran program
frequently has a module where the kind type parameters to be used
throughout the program are declared, and those parameters are then used,
by access to that module, throughout the program.  The Ada programmer
ought to be advised to define a type using

  RK: constant := 6;
  type Real_RK is digits RK;

The Fortran standard has, since 1990, required that a processor provide
a kind of complex corresponding to each kind of real, with the kind type
parameter specified in the same way as for real, and having the same
value as real objects of the same kind as the real and imaginary parts
of the complex object have.  Annex B.5 supports only single precision
complex.  The discussion in B.5(21.a) that reminds a programmer that it
is possible to instantiate a complex type corresponding to a Fortran
complex type and kind using, e.g.,

  package Complex_Types_RK is
    new Ada.Numeric.Generic_Complex_Types ( Real_RK );
  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
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
to avoid confusion with the Ada term "attribute," but in this context it
might introduce confusion instead.

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?

****************************************************************

From: Tucker Taft
Sent: Friday, November  2, 2012  9:46 AM

> 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.

I would suggest you contact Joyce Tokar who is now in charge of WG9:

     tokar@pyrrhusoft.com

****************************************************************

From: Tucker Taft
Sent: Friday, December  7, 2012  8:26 AM

     Sorry to just forward you to Joyce, when in fact she had forwarded you
to us! 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.

****************************************************************

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:

    http://www.ada-auth.org/AI12-SUMMARY.HTML

If you want to see *all* of the AIs ever written, go to:

    http://www.ada-auth.org/ais.html

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
http://j3-fortran.org/doc/year/12/12-007.pdf.  There are no textual differences.
The mechanical difference between this and the balloted version,
http://j3-fortran.org/doc/year/10/10-007r1.pdf, 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!

****************************************************************

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.

****************************************************************

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