!standard B.5 13-05-20 AI12-0058-1/02 !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 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. 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! ****************************************************************