!standard B.5                                   13-01-22    AI12-0058-1/00
!class Amendment 13-01-22
!status work item 13-01-22
!status received 12-07-03
!priority Medium
!difficulty Easy
!subject The Fortran Annex needs updating to support Fortran 2008
!summary

** TBD.

!problem

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.

!proposal

** TBD.

!wording

** TBD.

!discussion

Hopefully a Fortran expert can make specific proposals on this topic,
because most of the ARG has only a passing familarity with Fortran.

!example


!ASIS

!ACATS test


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

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