!standard B.5(27) 17-04-14 AI12-0224-1/01 !class presentation 17-04-14 !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). !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 nything from the Ada standard that is implemented by implementations (I know hat 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? ****************************************************************