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

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

!standard 1.2(3/5)          17-09-07 AI12-0224-1/03
!standard B.5(27)
!class presentation 17-04-14
!status Amendment 1-2012 17-07-21
!status ARG Approved 6-0-3 17-06-16
!status work item 17-02-22
!status received 17-02-22
!priority Low
!difficulty Easy
!qualifier Clarification
!subject Use of Fortran C Interfacing features
!summary
A note is added suggesting using the Ada C interfacing features with the Fortran C interfacing features to handle facilities not available in the Ada to Fortran interface.
!question
Some of the members of the INCITS Fortran committee (PL22.3) advise that Ada's Fortran interoperability should consist of using Ada's C interoperability with Fortran's C interoperability, without any direct Fortran interoperability.
Should Fortran interoperability be dropped? (No.)
!recommendation
(See Summary.)
!wording
Add after B.5(27):
For Fortran facilities not addressed by this subclause, consider using the Fortran to C interoperability features defined in ISO/IEC 1594-1:2018 along with the C interfacing features defined in B.3.
Change the reference in 1.2(3/5) to "2018".
!discussion
Dropping functionality that is widely implemented and presumably used from Ada is not a sensible alternative. However, it does make sense to use the Fortran C interoperability to access newer Fortran capabilities not currently available in B.5 (such as assumed-shape arrays - which correspond to unconstrained array parameters in Ada).
Note that we're assuming here that the new Fortran standard gets approved before the new Ada Standard (which, given our respective schedules, should be the case).
!corrigendum 1.2(3/5)
Replace the paragraph:
ISO/IEC 1539-1:2010, Information technology — Programming languages — Fortran — Part 1: Base language.
by:
ISO/IEC 1539-1:2018, Information technology — Programming languages — Fortran — Part 1: Base language.
!corrigendum B.5(27)
Insert after the paragraph:
NOTES
14 An object of a Fortran-compatible record type, declared in a library package or subprogram, can correspond to a Fortran common block; the type also corresponds to a Fortran "derived type".
the new paragraph:
15 For Fortran facilities not addressed by this subclause, consider using the Fortran to C interoperability features defined in ISO/IEC 1594-1:2018 along with the C interfacing features defined in B.3.
!ASIS
No ASIS effect.
!ACATS test
!appendix

From: Randy Brukardt
Sent: Wednesday, February 22, 2017  8:34 PM

Van Snyder sent me the following note that seems relevant to the group, so
I'm reposting it with permission:

-----Original Message-----

Several denizens of the INCITS Fortran committee (PL22.3) told me that Ada's
Fortran interoperability should consist of using Ada's C interoperability with
Fortran's C interoperability, and eliminate direct Fortran interoperability.
That would be a far larger change to your standard. I personally don't think
you should undertake that change, except perhaps to insert a non-normative
note.

The TS for further interoperability with C (29113) has now been incorporated
into the current draft of the next Fortran standard, which will be out for
Final Committee Draft ballot and comment next month, then out for Draft
International Standard ballot in July.  We call it Fortran 2015 because that's
when changes to the technical content were frozen, but it probably won't be
published by ISO until 2018.  If any Ada committee members want to look at the
draft, it will be available shortly after the end of February at
http://j3-fortran.org/doc/year/17/17-007r1.pdf.

The C interoperability facility now includes definitions of C macros to support
features not previously supported for C interoperability, such as optional
arguments, or assumed-shape arrays (arrays with <> bounds in Ada).
I don't think the Ada standard needs to say anything normative about Fortran's
C interoperability.  I leave it to you to decide whether to insert a
non-normative note urging readers to study the C interoperability features of
the Fortran standard, to determine whether and how they and the C
interoperability features of the Ada standard might conspire to accomodate
things they want to do that aren't directly accomodated by Ada's Fortran
interoperability features.

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

From: Randy Brukardt
Sent: Wednesday, February 22, 2017  8:36 PM

Here's my reply to Van:

> Several denizens of the INCITS Fortran committee (PL22.3) told me that 
> Ada's Fortran interoperability should consist of using Ada's C 
> interoperability with Fortran's C interoperability, and eliminate 
> direct Fortran interoperability.  That would be a far larger change to 
> your standard.  I personally don't think you should undertake that 
> change, except perhaps to insert a non-normative note.

I think (this is me personally) there is no chance that we would eliminate
anything from the Ada standard that is implemented by implementations (I know
that GNAT has Fortran support, and Janus/Ada used to support Microsoft Fortran
until that disappeared) and presumably used by Ada customers. The number of
things that we've actually eliminated from the Ada standard is very small (a
handful of pragmas that no one ever implemented or that were replaced by a
portable feature, an implementer could still implement such a thing as an
implementation-defined pragma); we're more likely to move something to the
"Obsolescent Features" Annex - but those remain a part of the Ada standard
that still have to be implemented [of course, Fortran support is optional,
and that wouldn't change]).

Maybe if that annex had existed in the early 1990s when the Fortran support
was introduced we'd have used it instead, but it seems way too late to change
that approach.

A note on the line that you suggested might make sense; best to run it by the
group and see if anyone has any strong opinions.

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

From: Jeff Cousins
Sent: Thursday, March 2, 2017  4:23 AM

Sticking with the corrections already underway in AI12-0058, but adding a
non-normative note about the C interface would seem sensible.  Though would
adding the note mean re-voting AI12-0058, require a new AI, or could it go in
a bucket AI of minor issues that aren't much more than editorial?

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

Questions? Ask the ACAA Technical Agent