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

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

!standard B.5          13-05-20 AI12-0058-1/01
!class Amendment 13-01-22
!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
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.
!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
-- 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 using
RK: constant := 6; type Real_RK is digits RK;
!wording
** TBD.
!discussion
There are further aspects of interfacing with Fortran that ought perhaps to be addressed as independent issues, probably resulting in more examples:
-- 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.
!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!

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

Questions? Ask the ACAA Technical Agent