!standard B.5(10) 17-04-24 AI12-0058-1/07 !standard B.5(18) !standard B.5(21) !standard B.5(31) !standard B.5(33) !standard 1.2(3/2) !class binding interpretation 13-05-20 !status Amendment 1-2012 16-10-27 !status WG9 Approved 17-06-16 !status ARG Approved 9-0-0 16-10-08 !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 In the Fortran Annex, update obsolete references and remove implementation advice that is considered to be bad practice, and add better support for double precision complex arithmetic. !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 double 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 of the terminology is wrong, with respect to the Fortran standard. For example, in the discussion of wide 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. 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. It would have been nice to include double precision i and j constants for the double precision imaginary type in Interfaces.Fortran (since there are such constants for single precision imaginary), but since constants can't be overloaded, that is not possible. One will have to use Double_Precision_Complex_Types.i and so on instead. 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 Modify 1.2(3/2): ISO/IEC 1539-1:[2004]{2010}, Information technology - Programming languages - Fortran - Part 1: Base language. Add after B.5(10): package Double_Precision_Complex_Types is new Ada.Numerics.Generic_Complex_Types (Double_Precision); type Double_Complex is new Double_Precision_Complex_Types.Complex; subtype Double_Imaginary is Double_Precision_Complex_Types.Imaginary; Modify AARM B.5(17.a): Ramification: The means by which the Complex {and Double_Complex types are} [type is] provided in Interfaces.Fortran creates a dependence of Interfaces.Fortran on Numerics.Generic_Complex_Types (see G.1.1). This dependence is intentional and unavoidable, if the Fortran-compatible Complex {and Double_Complex types are} [type is] to be useful in Ada code without duplicating facilities defined elsewhere. Modify B.5(18): The types Fortran_Integer, Real, Double_Precision, Logical, Complex, {Double_Complex, Character_Set,} and Fortran_Character are Fortran-compatible. Modify B.5(21): An implementation may add additional declarations to the Fortran interface packages. For example, [the Fortran interface package for an implementation of Fortran 77 (ANSI X3.9-1978) that defines types like Integer*n, Real*n, Logical*n, and Complex*n may contain the declarations of types named Integer_Star_n, Real_Star_n, Logical_Star_n, and Complex_Star_n. (This convention should not apply to Character*n, for which the Ada analog is the constrained array subtype Fortran_Character (1..n).) Similarly, the Fortran interface package for an implementation of Fortran 90 that provides multiple kinds of intrinsic types, e.g. Integer (Kind=n), Real (Kind=n), Logical (Kind=n), Complex (Kind=n), and Character (Kind=n), may contain the declarations of types with the recommended names Integer_Kind_n, Real_Kind_n, Logical_Kind_n, Complex_Kind_n, and Character_Kind_n]{declarations are permitted for the 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:2011}. Modify AARM B.5(21.a): {Reason: Fortran compilers 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.} Discussion: Implementations may add auxiliary declarations as needed to assist in the declarations of additional Fortran-compatible types. For example, [if a double precision complex type is defined, then Numerics.Generic_Complex_Types may be instantiated for the double precision type. Similarly,] if a wide character type is defined to match a Fortran 90 wide character type (accessible in Fortran 90 with the Kind [modifier]{attribute}), then an auxiliary character set may be declared to serve as its component type. Add after B.5(31): Precision: constant := 6; type Standard_Deviation is digits Precision with Convention => Fortran; Deviation : Standard_Deviation; -- Declarations to match the following Fortran declarations: -- integer, parameter :: precision = selected_real_kind(p=6) -- real(precision) :: deviation Add after B.5(33): Deviation := ...; !discussion This AI is mostly concerned with correcting obsolete references and practices mentioned in the Fortran Annex. There are further aspects of interfacing with Fortran that ought to be addressed as independent issues, probably resulting in more examples: 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 (29113), which will be incorporated into the next revision of the Fortran standard, specifies how these entities are described in C, by defining structs and functions to create, manipulate, and inquire descriptors and the objects they describe. Similarly, interoperation with Fortran modules (which are similar to Ada packages) are not mentioned. 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. Since interoperability with these features are described in a Technical Specification that has not yet been incorporated into the Fortran standard, it would be premature to standardize interfaces to these features from Ada; Those concerns should be addressed as part of a separate AI, ideally after the next Fortran standard is published. 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. Due to this perceived difficulty in designing and describing Ada interfaces to these features, the addition of interfaces to object-oriented features of Fortran should also be split off as a separate AI, as the decision to progress those features should be weighed independently from the main goals of this AI, which is mostly to update the existing content of the Fortran Annex. Other possible interfaces to Fortran not addressed by this AI include; -- 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. -- 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. !corrigendum 1.2(3/2) @drepl ISO/IEC 1539-1:2004, @i. @dby ISO/IEC 1539-1:2010, @i. !corrigendum B.5(10) @dinsa @xcode< @b Imaginary @b Single_Precision_Complex_Types.Imaginary; i : Imaginary @b Single_Precision_Complex_Types.i; j : Imaginary @b Single_Precision_Complex_Types.j;> @dinss @xcode< @b Double_Precision_Complex_Types @b @b Ada.Numerics.Generic_Complex_Types (Double_Precision);> @xcode< @b Double_Complex @b Double_Precision_Complex_Types.Complex;> @xcode< @b Double_Imaginary @b Double_Precision_Complex_Types.Imaginary;> !corrigendum B.5(18) @drepl The types Fortran_Integer, Real, Double_Precision, Logical, Complex, and Fortran_Character are Fortran-compatible. @dby The types Fortran_Integer, Real, Double_Precision, Logical, Complex, Double_Complex, Character_Set, and Fortran_Character are Fortran-compatible. !corrigendum B.5(21) @drepl An implementation may add additional declarations to the Fortran interface packages. For example, the Fortran interface package for an implementation of Fortran 77 (ANSI X3.9-1978) that defines types like Integer*@i, Real*@i, Logical*@i, and Complex*@i may contain the declarations of types named Integer_Star_@i, Real_Star_@i, Logical_Star_@i, and Complex_Star_@i. (This convention should not apply to Character*@i, for which the Ada analog is the constrained array subtype Fortran_Character (1..n).) Similarly, the Fortran interface package for an implementation of Fortran 90 that provides multiple kinds of intrinsic types, e.g. Integer (Kind=@i), Real (Kind=@i), Logical (Kind=@i), Complex (Kind=@i), and Character (Kind=@i), may contain the declarations of types with the recommended names Integer_Kind_@i, Real_Kind_@i, Logical_Kind_@i, Complex_Kind_@i, and Character_Kind_@i. @dby An implementation may add additional declarations to the Fortran interface packages. For example, declarations are permitted for the 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:2011. !corrigendum B.5(31) @dinsa @xcode< Rank : @b Fortran_Integer := 100; My_Matrix : Fortran_Matrix (1 .. Rank, 1 .. Rank);> @dinst @xcode< Precision: @b := 6; @b Standard_Deviation @b Precision @b Convention =@> Fortran; Deviation : Standard_Deviation; -- @FT<@I> -- @i -- @i> !corrigendum B.5(33) @dinsa @xcode< ... My_Matrix := ...; ... Invert (Rank, My_Matrix); ...> @dinst @xcode< Deviation := ...; ...> !example (See wording.) !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! **************************************************************** From: Tucker Taft Sent: Friday, September 18, 2015 10:04 PM Here is a proposal from Van Snyder about how to update the Fortran annex. I haven't evaluated it myself yet. ========================================================== Proposed changes to Subclause B.5 Replace paragraph 18: "Fortran intrinsic types are characterized by a parameter called a kind type parameter. If a kind type parameter is not specified, a processor-dependent default is assumed. The types Fortran_Integer, Real, Double_Precision, Logical, Complex, and Fortran_Character are compatible with the Fortran intrinsic types and kinds default integer, default real, double precision, default logical, default complex, and default character, respectively." There appears not to be a Double_Precision_Complex_Types package in Ada 2012. If there will be one in the next revision, add type Double_Complex is new Double_Precision_Complex_Types.Complex after paragraph 9, and add that and "double precision complex" to the above paragraph. I don't think it's necessary to have double precision versions of "Imaginary", "i", and "j". Fortran 2008 requires processors to support ASCII and ISO 10646 character kinds, in addition to whatever their default is. I don't know how to connect this to Ada. There is no mention of the Fortran ALLOCATABLE or POINTER attributes. Unlike C pointers, Fortran pointers are strongly type constrained, unless they are unlimited polymorphic pointers. Also unlike C pointers, Fortran pointers are "fat" in that if they are array pointers they contain bounds information. The target of an array pointer might be a non-contiguous section of an array. For example, consider an array A with dimensions (10,10), and a two-dimensional pointer P. A pointer assignment statement of the form "P => A(3:7,4:6)" would associate the noncontiguous section of A consisting of rows 3-7 and columns 4-6 with the pointer P, which thereby has runtime bounds of (1:5,1:3). Should the Ada standard contemplate interoperating with Fortran pointers? Fortran also defines a type C_PTR this is simply a C pointer. Should the Ada standard contemplate interoperating with Fortran objects of type C_PTR? If so, this should be mentioned in a paragraph after paragraph 19. I don't know what to recommend. For that purpose, however, it's probably sufficient for users to interface their Fortran procedure to Ada using Fortran's C interoperability features. Fortran allocatable objects are much more strongly constrained than pointers. They can be allocated and deallocated, but they are always contiguous and are automatically deallocated when they go out of dynamic scope. As with Fortran pointers, descriptors of allocatable objects that are arrays contain bounds and stride information. I don't know whether Ada has a type whose objects could be actual parameters that correspond to Fortran dummy arguments with the ALLOCATABLE attribute, unless the Ada processor is willing to conspire with a companion Fortran processor to use the same storage allocator. If the Ada standard should contemplate this interoperability, it should be mentioned in a paragraph after paragraph 19. I don't know what to recommend. An alternative to addressing these interoperability problems is to mention Fortran's support for C interoperability, and to recommend that an Ada program pretend that it is interoperating with C procedures when it is in fact it is interoperating with Fortran procedures that are C interoperable. Something like "It is possible for objects of other Ada types to be passed between Ada and Fortran programs. In a reference from an Ada program to a Fortran subprogram, the Ada actual parameters shall be compatible with C (B.3), the Fortran subprogram shall be described to the Ada program as if it were a C function, and the Fortran subprogram shall be declared within the Fortran program to have the BIND(C) attribute. In a reference from a Fortran program to an Ada subprogram, the Ada subprogram and its formal parameters shall be compatible with C (B.3) and the Ada subprogram shall be described to the Fortran program as if it were a C function. Refer to Clause 15 of the Fortran International Standard (ISO/IEC 1539-1)." A Fortran allocatable object could be an actual argument that corresponds to an Ada formal parameter, provided the Fortran description of the Ada subprogram's interface does not specify the parameter to be allocatable, and the Ada subprogram's formal parameter is not of a dynamically allocatable type. This probably doesn't need to be mentioned. It ought to just work. Fortran has polymorphic objects, but does not contemplate that these interoperate with C. Fortran's object-oriented system is based upon Simula's. The Fortran standard does not contemplate that polymorphic objects can interoperate with C++ polymorphic objects. It probably doesn't make sense for the Ada standard to contemplate that objects of tagged record types could interoperate with Fortran polymorphic objects. This should be mentioned in a paragraph after paragraph 19. Something like "There is no provision to interface objects of tagged record types with Fortran polymorphic objects." Components in Fortran derived types can have the POINTER or ALLOCATABLE attribute. If the Ada standard does not contemplate interoperating with objects with these attributes, it should be mentioned in a paragraph after paragraph 19 that there are no Ada record types whose objects can interoperate with Fortran derived-type objects that have components with these attributes. Something like "There are no Ada record types whose objects can interface with Fortran derived-type objects that have components with the ALLOCATABLE or POINTER attributes." Fortran dummy arguments can be of assumed shape, which means that the actual argument corresponding to an assumed-shape dummy argument is a descriptor that provides bound and stride information. The Fortran standard now contemplates that assumed-shape dummy arguments can interoperate with C parameters, in either direction. C macros to produce descriptors are described in Clause 15 of the Fortran standard. I don't know what to recommend here. If it is non contemplated that the Ada standard should support this interoperability, it might be mentioned that an Ada actual parameter cannot correspond to an assumed-shape Fortran dummy argument, and in a reference from a Fortran program to an Ada subprogram, the Ada formal parameter shall not be described as a Fortran assumed-shape array. If the Ada formal parameter is described as an explicit-shape or assumed-size array, it might result in copy-in/copy-out argument passing if the Fortran actual argument is not contiguous. Some Fortran compilers always use copy-in/copy-out without bothering to do a runtime check whether the actual argument is contiguous. Fortran dummy arguments can have the OPTIONAL attribute. I don't know whether Ada has an equivalent concept. Within paragraph 21, in the second line, insert "nonstandard" between "defines" and "types". At the end of paragraph 21, insert a sentence "The Fortran standard does not specify the values of kind type parameters. In particular, the value of a kind type parameter does not necessarily specify the number of bytes occupied by objects of that kind. Therefore if a Fortran interface package contains declarations of types with integer values for , whether those values correspond to Fortran kind type parameters with the same values depends upon the Fortran processor." (The notation means "n" in italic font.) I don't know what to do about paragraph 25. Fortran provides two attributes for derived types that affect the layout of components of objects of types with those attributes. The SEQUENCE attribute requires components to be laid out in the order they appear in the type definition, with no padding between them. See subclause 4.5.2.3 of the Fortran 2008 standard. Without the SEQUENCE attribute, the memory layout of components is processor dependent. The BIND(C) attribute requires all the components to be C interoperable, and that they be laid out as a companion C processor would lay them out. The Fortran standard does not specify what this means. The definition of a "companion" processor is processor dependent. Should an Ada actual parameter that is a data object of a Fortran compatible record type correspond to a Fortran dummy argument that has the SEQUENCE or BIND(C) attribute, or is the Ada processor expected to know its companion Fortran processor's derived-type component layout rules? I don't know what to recommend. In paragraph 26, replace "Fortran procedure" with "Fortran procedure's dummy procedure". Fortran has procedure pointers, which can be dummy procedures or components of objects of derived type. I don't know whether an access-to-subprogram object can have a convention denotation, and if so whether that ought to be mentioned in connection with associating an access-to-subprogram object with a Fortran procedure pointer. The Fortran standard does not contemplate that Fortran procedure pointers should interoperate with C function pointers. Rather, Fortran provides a C_FUNPTR type, and procedures to copy between that and Fortran procedure pointers. If the Ada standard does not contemplate a Fortran convention for access-to-subprogram objects, this might also be swept under the C interface rug. Otherwise, at the end of paragraph 26, add a sentence "An Ada parameter of access-to-subprogram type and Fortran convention may correspond to a Fortran argument that is a procedure pointer." I assume Ada records can have access-to-subprogram components, in which case also change the edit recommended above concerning Fortran derived-type objects with ALLOCATABLE or POINTER components by inserting "data" before "components". Fortran types can have type-bound procedures. I see no prospect for objects of these types interoperating with Ada. Fortran types can have finalization subroutines. I see no prospect for objects of these types interoperating with Ada. I don't know whether this deserves mention. **************************************************************** From: Randy Brukardt Sent: Thursday, October 1, 2015 10:06 PM You do remember that you volunteered to help him turn this into RM wording, right??? And that it's part of your homework for the upcoming meeting??? We need this to progress to something we can finish someday, not just endless proposals without RM-level details. **************************************************************** From: Brad Moore Sent: Sunday, October 2, 2016 12:54 AM Here is my first attempt to update the Fortran annex. [This is version /03 of the AI.] I just updated things that were obviously out of data, or incorrect, as suggested by the AI. However, I decided to leave out new interfaces to Fortran, with the thought that it would be better to cover those in a separate AI. For example, the AI mentions that there exists an ISO Technical Specification ISO TS 29133:2012, that defines how C can inter-operate with Fortran language features. This TS however is not yet incorporated into the Fortran standard, so it would appear to be premature to standardize Ada interfaces to Fortran using this information, and it would be better to wait for the next revision of the Fortran standard for this. Similarly, interfacing to Fortran object oriented types could be possible, but the level of difficulty to tackle this seems considerably higher than the rest of the updates in the AI, so the AI recommends that adding interfacing to OO Fortran features should probably be split off into a separate AI. **************************************************************** From: Randy Brukardt Sent: Monday, October 3, 2016 11:16 PM > Here is my first attempt to update the Fortran annex. You forgot to update the summary; it says "** Summary of actual changes.", which doesn't appear to be a real summary. ;-) > I just updated things that were obviously out of data, or incorrect, > as suggested by the AI. However, I decided to leave out new interfaces > to Fortran, with the thought that it would be better to cover those in > a separate AI. Yes, that makes sense. Get the easier issues dealt with first. I updated the format of the wording (it resembles some awful formatting from the parallel AI, which is too big to fix -- but let's not persist that format). **************************************************************** From: Brad Moore Sent: Monday, October 3, 2016 11:43 PM ... > You forgot to update the summary; it says "** Summary of actual > changes.", which doesn't appear to be a real summary. ;-) How about; "Update obsolete references and remove implementation device that is considered to be bad practice from the Fortran annex, and add better support for double precision complex arithmetic." >> I just updated things that were obviously out of data, or incorrect, >> as suggested by the AI. However, I decided to leave out new >> interfaces to Fortran, with the thought that it would be better to >> cover those in a separate AI. > > Yes, that makes sense. Get the easier issues dealt with first. > > I updated the format of the wording (it resembles some awful > formatting from the parallel AI, which is too big to fix -- but let's > not persist that format). What sort of formatting issues are you seeing, so I can avoid them in the future? **************************************************************** From: Jeff Cousins Sent: Tuesday, October 4, 2016 1:47 AM Many thanks Brad for making a start on this. Once it's polished, would you mind if I put it past a Fortran expert? **************************************************************** From: Tucker Taft Sent: Tuesday, October 4, 2016 8:19 AM And hopefully it will be shared with Van Snyder, our other Fortran expert, who is already somewhat involved. By the way, Brad, did you start with the work that Van Synder had already done? If not, that might be my fault. He sent me something a long time ago, which I had presumed had been shared with the whole ARG, but perhaps not. **************************************************************** From: Brad Moore Sent: Tuesday, October 4, 2016 10:08 AM It would definitely be worthwhile to have Van Snyder, and any other Fortran experts review the changes. I carefully reviewed all of Van Snyder's comments which were captured in the appendix and the existing AI. His comments were extremely helpful, as his comments and suggestions made it quite easy for me to produce the submitted AI. The changes I made were low hanging fruit that updated existing interfaces to Fortran. We'd really want to have someone from WG5 look at our work, if and when we start introducing newer interfaces to the Annex, such as OO features or pointers and storage pools. It was interesting also to brush up on my Fortran as I attempted to refamiliarize myself with the language. It was interesting to see that Ada shares some design features with Fortran in some areas, for instance being able to name parameters at the call site, and I see similarities with allocation, private parts, type extension, storage management. **************************************************************** From: Randy Brukardt Sent: Tuesday, October 4, 2016 1:58 PM > And hopefully it will be shared with Van Snyder, our other Fortran > expert, who is already somewhat involved. I, of course, sent it to Van as soon as I started working on it yesterday. I asked for comments before the upcoming meeting (both to give him a deadline and also so we have them before any discussion). There's a reason that I get paid the big bucks!!! :-) I'll send him the revised version this afternoon (as soon as I do it). **************************************************************** From: Randy Brukardt Sent: Wednesday, October 5, 2016 5:43 PM ... > What sort of formatting issues are you seeing, so I can avoid them in > the future? * Paragraph numbers not following the AI style guide: a space before the '(', not "AARM" before AARM paragraph numbers; * Change instructions not following one of the usual formats: Modify : Replace with Append to : * As suggested by the above, usually (but not always), the RM text is indented a bit. And it *never* has quote marks around it unless it appears in some other text (generally, only in the question or discussion). * Some of the text lines exceed 80 characters, which caused the text I got to get ragged. (I'm not sure if a tool was doing that on my end or if the original was funky; Notepad couldn't display the original versions [and I can't get Outlook to let me use an alternative reader] so I had to process them to read them.) I probably would have let one of these go, but there were enough issues that it made more sense to just clean it up. (It's much like Tucker and the inevitable double space after a period. We decided long ago that there would only be a single space after a period, and I had to retrain myself that way. Tuck never got that memo, and I decide to change his text mainly if there is something else wrong with it. Else I could be doing that all week...) **************************************************************** From: Randy Brukardt Sent: Wednesday, October 5, 2016 6:35 PM > > And hopefully it will be shared with Van Snyder, our other Fortran > > expert, who is already somewhat involved. > > I, of course, sent it to Van as soon as I started working on it > yesterday. I just received the following reply from Van: The AI draft you sent looks fine. The only detail that might be changed, which isn't really important, is that I was recently told that both Simula and Oberon influenced the design of the object-oriented features in Fortran. ***************************************************************