Project 20: Fortran [Update of Introduction by John Reid received on 25-2-2023] Since its introduction by IBM in 1956, Fortran has had seven standards, commonly identified as Fortran 66, Fortran 77, Fortran 90, Fortran 95, Fortran 2003, Fortran 2008, and Fortran 2018. The tradition was to designate the version by the year in which technical development work was completed rather than the year of publication, but this was changed for Fortran 2018, which was published in 2018. Fortran 66, Fortran 77 and Fortran 90 were developed by committee J3 under the aegis of the Accredited Standards Committee X3J3, sponsored by the Computer and Business Equipment Manufacturers Association (CBEMA), later the Information Technology Industry Council, and accredited by the American Standards Association, later the American National Standards Institute. Before the development of Fortran 77, the Organization for International Standardization (ISO) convened Technical Committee 97, later reorganized as a working group under the aegis of Joint Technology Committee 1 (JTC1) with the International Electrotechnology Commission (IEC), subcommittee 22 (SC22), designated ISO/IEC JTC1/SC22/WG5. There was significant friction between WG5 and X3J3 during the development of Fortran 90. This, along with conflicting desires of users for more features and vendors for less work, and conflicts between vendors who had implemented similar new features in different ways, contributed to the delay in developing Fortran 90, which for a time was called Future Fortrans and then Fortran 8x. Since completion of Fortran 90, X3J3 and WG5 have fortunately had harmonious relations, the agreement being that WG5 sets the requirements and X3J3 develops the standard according to those requirements. In 1996, CBEMA was renamed Accredited Standards Committee NCITS, National Committee for Information Technology Standards, by then a subcommittee of the Information Technology Industry Council. The designation of X3J3 was changed to NCITS/J3. NCITS later changed their name to the InterNational Committee for Information Technology Standards, and then changed the designation of the Fortran working group to INCITS/PL22.3, to articulate their designation with the ISO designation. Many WG 2.5 members have contributed to the development of Fortran. Smith, Reid, and Snyder served on X3J3. Paul and Feldman were consultants to X3J3. Reid, Walter and Snyder were members of WG5, and Reid was its convenor, 2000-2017. Snyder is an Emeritus Member of PL22.3 and Reid is an alternate member Members of IFIP WG 2.5 are encouraged to take an active role in future development of Fortran. --------------------------------------------------------------------- Baden 1978: =========== Double PRECISION COMPLEX featured predominantly in the discussions. Dr. Smith said that X3J3 see this as merely the addition of a single facility at great expense. Dr. Lawson moved that Dr. Reid's paper be sent to ISO and X3J3 and offered to look at it further. Professor Hull thought that steady pressure should be brought on X3J3 so that, perhaps, FORTRAN 82 would have the required facility. It was therefore decided to send Dr. Reid's paper, together with a covering letter to X3J3 and also to send the material to FORWORD for publication. Dr. Smith explained that he is not yet a member of X3J3 and hasn't yet done the necessary work. In January he hoped to spend most of his time in preparing a 'position'. Novosibirsk 1979: ================= X3J3 Fortran Standard Smith (now a member of X3J3) explained the current philosophy of the committee and asked for reactions from the working group, particularly on the precision proposal, array processing and the group proposal. His remarks and and details of these proposals in IFIP/WG 2.5 (Novosibirsk-13) 613. Fosdick asked whether a Fortran 77 compiler with extensions was regarded as standard. Smith said that this was so, but there is now a Federal requirement in any government contract for some means of flagging non-standard features. There followed a discussion on desirable array features, which was eventually deferred to ab evening session by a sub-group (Smith, Rice, Reinsch, Redid, Einarsson, Fosdick) whose report is IFIP/WG 2.5 (Novosibirsk-15) 615. Lawson expressed reservations about language features being able to give all the flexibility, error flags, etc. that subroutine calls can give. Dekker was concerned about what numerical methods would be used for solving linear systems, etc. if done by the compiler. Gear pointed out that a compiler would actually call on a library so it should not be difficult to change the algorithm. Rice presented subcommittee report on array facilities. Comments should be sent to Smith soon so that he can present a revised version to the January meeting of X3J3. Smith invited comments on the precision proposal. Hull asked about precision blocks and Smith said they would have to be subroutines or groups. The group proposal was generally welcomed. ERDA Fortran extension. Smith explained that the Department of energy wanted an extension of Fortran 77 to permit portability between different projects. Three members of X3J3 are participating, experimenting with new ideas. Includes macro processor, more control structures, more flexible program form, bit data type, extended character set, environment parameters, intrinsics, double complex, groups. Committee is now proceeding from functional to syntactical design. Harwell 1980: ============= Current work of the X3J3 Fortran committee Smith summarized aspects of the current work of X3J3 that are important for numerical software and invited discussion. He also introduced three documents (IFIP/WG 2.5 (Harwell-20/21/22) 720/721/722) that he has prepared for X3J3 and invited comments. Discussion Smith: Because I have been thinking about various lengths for floating-point numbers I have been asked to consider also provision for varying lengths of integers. Smith: The concept of storage association is likely to be removed altogether. For instance the real and imaginary parts of a complex number will be obtainable only through calling intrinsic functions. Gear: Does this mean that complex numbers could be held as (radius, angle), or with a shared exponent for the real and imaginary parts? Should we take a view on this? Smith: The intent is that this is not allowed. Smith: Some form of macro facility is likely, although the original proposal was rejected for being too complicated. Smith: Automatic storage management (c.f. Algol 60) is likely, which will be useful for workspace for library subroutines, for example. Smith: Currently there is a proposal for grouping subroutines and one for permitting internal subroutines. Since they serve such similar purposes it is unlikely that both will be adopted. Rice: Do all members of a group have to be compiled together? Smith: This has not yet been specified. Independent compilation is certainly feasible. Ford: What happens if the precision requested is not available? It is important that the machine does not go ahead doing nonsense (something NAG has experienced). Smith: I would like to see a clear diagnostic, but cannot promise that it will be there Smith: There is a problem over ordering real types because each involves a precision and a range. Currently we require only that the given requirements are met and not that they are met minimally because it may be impossible to determine which of two possible types is minimal. Rice: Does this mean that a processor may use a ridiculously high precision, so provoking a failure later when more precision is requested? Smith: Yes. I would like to avoid this by ordering the levels, requiring that level j+l should at least match level j in both precision and range, but there is opposition to the possibility of imposing any restriction on a manufacturer's hardware. Reid: The level numbers themselves provide an order so why not require the least level that meets the requirements to be used? Smith: Yes, this is intended, and I believe that market pressures will ensure that the resulting actual implementations will be sensible. Van der Meulen: What about mixing types in arithmetic? Smith: The goal is to have a complete set of conversion rules. ---- Reid reported that the double complex paper had been published in SIGNUM newsletter (Mar 80), IMANA newsletter (Oct 79) and has been accepted for publication in the IMA bulletin. The paper on "Functions for manipulating floating-point numbers" has been published in the SIGNUM newsletter (Dec 79), ALGOL bulletin and in SIGPLAN notices. Both these papers were also sent to X3J3 and a letter has been received from the chairman (IFIP/WG 2.5 (Harwell-35)735). No action was taken on double complex (vote 19-1) and the other paper will be considered later. ---- The precision proposal for X3J3 Meanwhile a subcommittee consisting of the remaining working group members (Smith, Ford, Dekker, Gear, Hull, Reinsch, Rice) considered a proposal from Smith that the group write a letter to X3J3 setting out its opinion on the precision proposal. A draft letter by Smith was discussed and approved subject to changes whose exact wording would be chosen by the secretary in consultation with Smith. The secretary was asked to send the revised letter to the X3J3 chairman to arrive by July 1st, preferably after the chairman and vice-chairman have commented. The final letter is document IFIP/WG 2.5 (Harwell-31)731. Boulder 1981: ============= Smith handed out copies of the current version (S6.78) of X3J3 document S6 (IFIP/WG 2.5 (Boulder-26)826). This includes all proposals accepted for Fortran 8x and is updated soon after each meeting. He urged everyone to study it. X3J3 wants individuals to comment in writing. They would also like guidance from this meeting since they have been given a wide variety of advice. Comments to X3J3 should include background information and must consider other areas. The numerical software community is not large but its products are widely used. They want each community to consider whether its needs will be met. Since 1977 the committee has been looking for ideas in other languages, through tutorials, etc. (all recorded in the minutes). They hope S6 will be written to describe the draft language (core plus modules) by summer 1982, to be followed by three years of discussion. The language will not be in use until at least 1990. Hull commented on the emotional feelings expressed at the working conference, including unfortunate and undiplomatic attacks. Smith said that X3J3 members eventually felt they could distinguish serious comments from the rest and that no permanent damage was done. Rice wondered what our response should be. We must act on what members of the group have said, particularly on preprocessors. Smith said that X3J3 has considered the needs of preprocessors and has provided the necessary hooks, e.g. with macros. Battiste remarked that X3J3 has been overwhelmed by the needs of large-scale computing but he sees it as being widely used on micros. Smith replied that the committee talks of a small core language, which might be suitable for micros. Cody remarked that manufacturers are likely to extend Fortran to take advantage of their special hardware features. Smith agreed that manufacturers do tend to think of their own needs, which is one reason for sending representatives. But they also do want advice from X3J3. Cody pointed out that past standards have also contained a subset language. He hoped that subset Fortran 8x would be part of the core. Smith remarked that there have not been many implementations of the subsets. Battiste said that micro manufacturers are mostly working with full Fortran 66. Rice said that he has talked with Alan Wilson on the array facilities and is convinced that they can be improved. Einarsson wondered if we should solicit test codes written in array format, say in SIGNUM Newsletter. Smith said that it is very worthwhile to try writing code in a new language. He has done this in his talk at the working conference. Reinsch remarked that the array facilities drew flak from a certain corner of the audience and wondered if they have full X3J3 support in their present form. Ford emphasized the need for environmental parameters and intrinsics in the core. Rice reported back from the Fortran 8x subgroup. It proposed two motions --- ISO/TC97/SC5 Fortran meeting The next "Fortran experts" meeting will be in Vienna in June 1982. Stetter said that he will be there, but that it was important to get another group member there too. Reid said he hoped to go. He attended the last meeting in Amsterdam in October 1980 and was very impressed with the attentiveness of the X3J3 members there. He was invited to give his paper (IFIP/WG 2.5 (Boulder-8) 808) at the Berkeley meeting of X3J3 in January 1981. Rice moved that Reid be appointed to represent the group and this was approved nem con. Madison 1982: ============= Review of Fortran 8x -------------------- Smith mentioned the following changes since the last WG 2.5 meeting: i) real precision specification accepted, including a generic facility; ii) shared data subprogram defined; it replaces GLOBAL and may eventually include the functionality of USING and interfaces; iii) internal procedures accepted; iv) entity-oriented specifications passed; v) name directed I/O (NAMELIST) passed; vi) data structures passed; and vii) simple "include" macro passed. The immediate priority of X3J3 is the merging of Fortran 77 and S6 (which summarizes the additions to Fortran 77) into a single document defining the new language. The problem of defining the core language and the extension modules is essentially unresolved. Smith offered to make a copy of the latest S6 for anyone interested. He recommended Reid's paper IFIP/WG 2.5(Madison-16)916, which summarizes the advances from the point of view of mathematical software. He also mentioned his own paper "Fortran 8x features which support the development of numerical subroutine libraries", Oak Ridge National Laboratory. Ford asked about the scientific module. Smith said that he was against it and thinks that the idea has been abandoned. The paper of Delves, DuCroz and Reid (IFIP/WG 2.5(Madison-18)918), presented at Vienna, will help. Rice asked whether the idea was to build on the core and Smith that the current idea was to break up the language. ISO Fortran experts meeting at Vienna ------------------------------------- Reid reported on the ISO Fortran experts meeting in Vienna. He presented three papers there. IFIP/WG 2.5(Madison-16)916, which was checked by Jeremy DuCroz of NAG, summarizes the improvements since the last ISO Fortran experts meeting in 1980. IFIP/WG 2.5(Madison-17)917, which also was checked by Jeremy DuCroz, proposes a "parallel do" construct in order to obtain parallelism in a simple yet flexible way and was sympathetically received, particularly by Jerry Wagener. IFIP/WG 2.5(Madison-18)918, which is a joint paper with Delves and DuCroz resulted from a NAG meeting in London. It suggests a new criterion for separating modules from the core, namely that features in a module should be expressible in terms of the core language. It also suggested that user definition of operators should be permissible. The ideas were sympathetically received. Kulisch talked about his new arithmetic (see IFIP/WG 2.5(Madison-5)905) and received an overwhelming straw vote (18 for, 2 against, 9 abstentions) for "wanting X3J3 to pursue these ideas". Hull asked how the idea of Delves et al should be named. Ford said that a new name may be needed and remarked that once one has experienced using one's own operators one never wants to give up the facility. Smith said that X3J3 feels that there has not been enough experience with user- defined operators. Ford asked how important it was for Europeans to attend ISO experts meetings as opposed to X3J3 meetings. Reid said that X3J3 is clearly anxious to get European opinion and 7 members took the trouble to come. Smith said that ISO approval is required. Proposal on inclusion of pointers in Fortran 8x ----------------------------------------------- Gentleman proposed the following motion. WG 2.5 wishes to express the need for some pointer mechanism to be present in Fortran 8x. This mechanism would make it possible to save the name of an object in a variable, and to reference the object whose name is contained in a variable. Pointers could be compared for equality, or tested for null, as well as assigned. Some doubt was expressed about the group having the energy to pursue this as well as the array proposals and user-defined operators. On a straw vote 4 were for, 1 against and 6 did not know. No decision on further action was taken. Proposal on user-defined operators in Fortran 8x ------------------------------------------------ The following motion was proposed by Hull, and seconded by Stetter. It passed by 11 votes to nil. WG 2.5 supports the addition of user-defined operators to Fortran 8x. This addition would permit certain features (such as COMPLEX) to be moved from the core to an extension module without loss of portability. It would also permit extensions which would very much enhance the value of user-defined data types (such as what was proposed by Kulisch at Vienna to improve the accuracy of scientific computations). Soederkoeping 1983: =================== Array facilities. ----------------- Document IFIP/WG 2.5 (Soederkoeping- 19) 1019 is to appear in SIGNUM Newsletter. Rice felt the necessity to standardize array facilities quickly and was willing to work on it. The group generally agreed, but rejected the suggestion that Reid should pursue the activity for an appendix to Fortran 77 by 6 no, 6 yes, 5 abstentions. Event Handling. --------------- Smith reported that the Fortran committee has accepted an event handling facility for Fortran 8X. As accepted in May 1983, it is a general facility that adds a new intrinsic type 'event mark' to the language which names an event and specifies conditions which will raise the event. Executable statements which activate the event, record its occurrence and connect a handler to the event, are defined. Static block constructs called SUSPEND blocks are defined that require the suspension of all active events within the block. The handlers connected to an event are like internal procedures except that a RETURN statement is not permitted. Instead of a RETURN Statement, a RESUME or RETURNUP statement may be used. A RESUME statement specifies that there is a return to the statement after the statement in which the event was raised. The RETURNUP statement has the same effect as executing a RETURN statement from the procedure in which the event was raised. While the handler may have access to entities within the procedure that caused sed the event, no mechanism is provided to return a result of a particular operation that caused the event. Although it is not specified now, the arithmetic events such as E FIXEDOVERFLOW, UNDERFLOW, OVERFLOW and ZERODIVIDE are expected to be proposed as intrinsic events in the language. See IFIP/WG 2.5 (Soederkoeping-13) revised. The group discussed this exception handling mechanism and expressed its support for the activity of Smith, Reid in X3J3 Committee on exception handling, it hoped that Hull would comment once he has received the papers on it. Pasadena 1984: ============== Fortran 8x Report (Smith and Reid) ---------------------------------- The Fortran standards committee X3J3 is actively working towards the completion of the next draft Fortran standard. Proposals for additional facilities will not be considered beyond the August 1984 meeting. The committee at this time is in the process of the final re-organization of its basis document far the draft standard. The committee expects to spend the next 4 meetings preparing the draft standard, using the new organization. The committee expects to complete the draft standard by the August 1985 meeting. The document will then be submitted to X3 for approval for distribution to the user community for public comment. In order to inform the Fortran user community as to the contents of Fortran 8x, X3J3 is organizing Fortran Forums immediately before or after the X3J3 meetings for the next year. The first Fortran Forum will be held on August 13th 1984, at Colorado State University in Fort Collins, Co. Further to this end, the Fortran Information Bulletin which briefly discusses the contents of Fortran 8x is to be published as a SIGNUM and FORTEC special issue in July or August 1984. A questionnaire will accompany the bulletin. It is hoped that the questionnaire will provide feed-back to the committee as to the appropriateness of the proposed extension to Fortran 77. This Fortran Information Bulletin was recently submitted to the parent committee X3 for approval for publication. This document received 3 negative votes out of approximately 40 votes. The main reasons for the negative votes were the belief that the proposed language was too large, and that the compatibility between Fortran 77 and Fortran 8x was not clearly defined. There was much discussion at the last meeting about the size of language and a "hit-list" of about 30 possible deletions was formed. Straw votes at an evening meeting indicated, however, that only a few of them had enough support for a formal proposal for deletion to succeed. Thus a small reduction in the size of the language is possible but not a large reduction, unless there is a howl of protest in the period of public review. Moves to spell out the way new features may be intermixed with old are likely. Reid is concerned about the move from Fortran 77 to Fortran 8x. How one can ease the upgrading, and the efficiency of the next Fortran compiler ? Vouk ask if there are incompatibility features between 66, 77 and 8x. All 77 is in 8x, but there are incompatibilities between F 66 and F 77. Gentleman thinks that a rationale would be useful. Lawson asks if there is a financial support of the EISPACK 8x project. The answer is no. Wright ask Smith and Reid if they are happy about the work accomplished. Reid says yes: The European were well received. Smith says yes: the Numerical Analysts were well received. Reid is concerned about the size of the language (10 times the Fortran 77 compiler size). Rice feels the compiler size is crucial and Smith recommends that people write to the Committee on that issue Ford wishes to thank Reid and Smith for their dedicated work on the X3J3 committee. Sophia-Antipolis 1985: ====================== Fortran 8x-X3J3 activities since June 1984 (Smith) -------------------------------------------------- Since the last WG 2.5 meeting in June 1984 in Pasadena, the Fortran committee has been concentrating on the final document for Fortran 8x, currently called standing document S8. This new document is a reorganization of the previous document motivated by the need to describe Fortran 8x in a consistent understandable but concise manner. This document, although currently a working document of X3J3, will undoubtedly be available by November 1985. The major changes in the proposed language have been: 1) reintroduction of a bit data type, based upon the concept of a single datum, called a bit. (The previous bit data type facility was based upon a string of bits, patterned after the character data type). 2) "unifying concepts", to unify and make more consistent the proposed features in Fortran 8x. This activity involves making each individual facility consistent with itself, other proposed new facilities and the existing Fortran 77 facilities. Examples of these activities include: a) The old form of the DO loop becomes a special case of the DO-block construct. b) The floating-point types REAL and DOUBLE PRECISION are processor-dependent ways to specify certain generalized precision data types. c) Entity-oriented specification statements are compatible with the existing attribute-oriented specification statements. Currently, the committee has rejected pointers, and the mechanism to permit user-defined derived-type input/output. The original event-handling facility has now been rejected. A simpler exception-handling facility has been accepted to replace the original event-handling facility but it has not been properly described or incorporated in the current standing document. The committee has been active in searching for ways to reduce the new proposed facilities for Fortran 8x. There have been several facilities that have been removed to date (e.g. macros and varying character). The committee is still studying ways to reduce the size of Fortran 8x. For example, keyword arguments in the enhanced call facility are being considered for deletion from Fortran 8x. The Fortran committee plans to forward a draft proposed standard to X3 for permission to publish the draft standard for public review as soon as possible after the November 1985 meeting. There may be an additional meeting in January 1986, to accomplish this task. The Group discussed the conflict between the time limit and the need to reduce the size of the language. Argonne 1986: ============= J. Reid informed the group about the status of the Fortran 8X standardization effort. J. Rice chaired during this presentation. There had been six meetings of X3J3 since the Working Group last met. In July 1985 at Oxford (the first meeting outside N. America) it was busy editing the draft standard and it combined the two forms of the DO. In September 1985 at Los Alamos, editorial work continued (including actual keying of text by members to speed the process), the CONTAINS statement was added to precede any set of internal procedures and thereby avoid a possible syntax ambiguity, and it was decided that masked array expressions such as SUM (A/B,MASK=B.NE.O.) should require full evaluation of masked arguments (following the normal conventions for procedure calls). In November 1985 at Tulsa, editorial work continued. Also it was decided to require an explicit interface when calling procedures having assumed-shape dummy arguments (to permit interfacing to compiled code that expects 'call by address'), to deprecate REAL and DOUBLE PRECISION DO indices, and to add RANGE (so that arrays or sets of arrays may have extents in each dimension that are dynamically adjustable within the corresponding declared extents). In January 1986 at Sunnyvale, more than a thousand editorial changes were accepted and by a 17-11 roll-call vote the committee decided to conduct a letter ballot on whether the draft was ready for release for public comment. Most of those voting against the ballot were concerned that the document was still rather unpolished. In April 1986 at Scranton, the ballot result was announced as 16 yeses (many with comments), 19 noes (all explaining their reasons), and 2 did not vote (1 later voted 'no'). The noes were principally on the grounds of thinking that the deprecation rule was too strong or that the language was too big. A large subgroup worked all week seeking compromise. On deprecation, it was suggested that a very short list of deprecated features with replacements in Fortran 77 be called 'obsolescent' and be recommended for deletion from Fortran 9y if they become little used and that the rest be candidates for the next obsolescent list and possible removal from Fortran 10z. This satisfied everyone except Dick Weaver (IBM) who wanted no deprecation at all. No compromise on language size achieved a 2/3 majority. In June 1986 at Mount Kisco, the changes to deprecation were passed and so were the following changes that reduce the size of the language: Move to appendix: arrays of arrays error handling operator overloading structure constructors DIAGONAL, RANK, REPLICATE, PROJECT, FIRSTLOC, LASTLOC nested internal procedures FORALL IDENTIFY vector-valued subscripts variant structures BIT Simplify USE, Add bit transfer capability, Remove significant blanks and insignificant underscores, Replace name-directed i/o by NAMELIST, Unify IDENTIFY and RANGE. The committee members were then asked how they expected to vote in November if all these changes have been satisfactorily incorporated into the draft by then. The result was 22-4, which suggests that the possibility of deadlock has been avoided. A discussion concerning the proposed Fortran document appendix and some other features followed. The prevailing opinion in the group was that elements of the language had been moved in and out of the standard without a sound reason. M. Delves proposed that the Working Group contact/write to the X3J3 concerning the cleanliness of the language constructs. X3J3 liaison (Reid) needed some input/reaction from the group for X3J3. B. Ford was of the opinion that X3J3 should publish the Fortran 8X document for public review. If X3 stopped this then ISO should be asked to put the document out. An alternative was to distribute the document informally. Ford offered to handle copying and distribution for U.K. C. Lawson said that all the deprecated features could be, and should be, handled through portable pre-processors. He also noted that by the time the new Fortran standard became prevasive (a 10-12 year lag behind the year 8X), Ada would be quite widespread, and one should seriously consider consistency of the Fortran features and the Ada features (e.g names). The third point he made was that given the current state of the 8X effort there was a distinct possibility of a disaster with the public review of the 8X document, and this should be considered. G. Paul responded to the above comments as a member of the X3J3. He said that going to ISO was not simple. Once the document passed to X3 it became their document. ISO should be the initiator of any distribution action. The preprocessor idea was discussed within X3J3. In fact, one of the reasons behind the two lists of "obsolete" features was just that. Consistency with Ada may be desirable. It was noted that X3J3 had done a commendable job distributing comments and the documentation, however, a rationale for 8X, and a formal review of the S8 were needed (Feldman, Ford). Rice noted that X3J3 kept changing the document, so a firm release date. should_ be set. In the discussion that followed it was pointed out that a rationale for S6 existed but it was not general enough, and some of features needed reconsideration (e.g. pointers, optimization, FORALL etc.), (Feldman, Reid, Dekker). The following general motions regarding Fortran 8X were passed by WG 2.5. Motion by B. Ford (seconded by Feldman, Delves): We recommend that X3J3 prepare a brief rationale (of about 10. pages) for the Fortran 8X draft standard. Motion by J. Rice (seconded by Ford, Delves): The Fortran 8X draft standard should be put out for public review as soon as possible. Working Group discussed possible implications of the Fortran 8X document disaster. The worst case scenario: deadlock in the committee (Rice, Delves, Reid, Paul, Ford). It was noted that there were signs of weariness in the X3J3 committee itself. There was also the question of the Charter. If no product appeared within 10 years of its formation the J3 would be dissolved, and the whole process might start anew (Smith, Paul). It was agreed that pointers and arithmetic consequences of the standard (Feldman), operator overloading (Delves), nesting and passing of internal procedures (Ford), and BIT (Lawson) should receive additional attention. The following motions regarding technical Fortran 8X issues were passed by the group. Motion by H. Stetter and S. Feldman (seconded by Smith): We strongly recommend that a pointer facility be added to the Fortran 8X language. Motion by B. Ford (seconded by Lawson): We strongly recommend that the passing of internal procedures be permitted. Como 1987: ========== Smith presented to the group the current state of the Fortran 8x standardization effort. He said that there were about 100 changes pending and that the X3 document was still being held back as far as the public review is concerned. In the discussion that followed it was noted by Reid that only some of the WG 2.5 motions passed last year regarding Fortran 8x have been adopted by X3J3. In particular there was no progress regarding motions concerning pointers (but see 4.9) and passing of internal procedures (p16 of IFIP/WG 2.5 (Argonne-3) 1303). The general feeling in the group was that the draft standard should be made public as soon as possible. (Reid, Ford, Rice, Smith, Delves) Motions: 1) IFIP/WG 2.5 reaffirms its belief that the current draft of Fortran 8x should be released as soon as possible for public review, and notes with approval the recent vote in favour of this by X3J3. 2) IFIP/WG 2.5 urges X3 and ISO TC97/SC22 to send the draft standard out for public comment as soon as possible. Gentleman noted that WG 2.5 should be monitoring other languages besides Fortran and Ada (Ford). After a discussion the group concluded that C is one of the languages that is important for the numerical software community and its standardization should be of interest to the group. It was decided to form a C language interest subgroup (see project [64]). --------------- ICIAM Mini-symposium on Fortran 8x. G. Paul and B. Smith could not go to the ICIAM meeting, but Mike Metcalf and Lawrie Schonfelder have agreed to substitute for them. The mini-symposium was on Tuesday morning and lasted two hours. It was divided into four sessions of half and hour, each including discussion. The sessions were: "Overviewing of Fortran 8x" (Metcalf), "The Fortran 8x Array Features" (Reid), "Generalized Precision Features in Fortran 8x" (Schonfelder), and "Fortran 8x: A Users's Perspective" (Feldman). The IFIP/WG 2.5 thanked all the members of WG 2.5 who were involved in organizing the mini-symposia. Stanford 1988: ============== Documents: IFlP/WG 2.5 (Stanford-7) 1507, 2 pages, IFIP/WG 2.5 (Stanford-29) 1529, 2 pages. Also reports in subsections 3.7 (Paul) and 3.8 (Smith). The following is the summary of the report presented by J. Reid . X3J3 voted (26-9) in May 1987 to release its draft standard for public comment, but there was a delay because of opposition in the parent committee X3. Most of those voting 'no' wished a) to see less new features and more standardization of existing non-standard practices, b) to see the lists of deprecated and obsolescent features reduced or removed. The final X3 vote was 30-5 and the public comment period ran for four months from October 23rd, 1988. J. Reid sent in a comment on behalf of the group ( 1507) after consulting the members of the FORTRAN projects. In addition, eight group members sent in comments either as individuals or as members of organizations. In all, about 400 comments were received, a pile of paper about 4 inches thick. A majority were negative to the draft, wanting a much less complex language, less additions to F77, and no deprecation for COMMON and EQUIVALENCE. However, many of these were form letters and a significant number of carefully written supportive letters were received. The draft was also subjected to ISO review. This was much more supportive. There were request for bits, significant blanks, pointers, multi-byte characters, vector-valued subscripts, stream I/O, and short integers. There was also a wish to reduce the complexity. Several plans for responding to the comments were discussed at the last X2J3 meeting. Only four were still active at the end of the meeting and are summarized in document number 1529. That of Adams et al. is a personal attempt by five members to respond to the ISO comments. The remaining three were attempts to respond to the ANSI comments. None received the necessary 2/3 majority support (the final straw votes on these three plans as a base were 15-14- 6, 19-12-3, and 12-17-4) so the committee remains in deadlock Beijing 1989: ============= Paul summarized the results of X3J3 work that took place since WG 2.5 Stanford meeting. He pointed out that the new ISO Fortran standard will go through the last public review cycle this year, and probably be approved sometimes in 1990. The ANSI standard (Fortran 8x) is lagging behind, although the WG 2.5 letter (Stanford document 1531), and presentation to X3J3 by J. Rice, has helped speed up the standardization effort. Jerusalem 1990: =============== Documents: IFIP/WG 2.5 (Jerusalem-9) 1709, 10 pages, IFIP/WG 2.5 (Jerusalem-10) 1710, 2 pages. Reid's report was discussed and his request for letter to X3 with a copy to ISO was accepted (Feldman, Bercovier, Vouk, Rice, Fosdick, Kulisch). A vote was taken on three points: 1. ISO work should be welcomed (Y: unanimous). 2. Continuance of Fortran 77 is regrettable (Y: 4, N or A: 6) 3. It is not desirable that Fortran 90 diverges from ISO possibly resulting in two F90 standards (Y: unanimous). Karlsruhe 1991: =============== Document: IFIP/WG 2.5 (Karlsruhe-18) 1818, 2 pages, Following the Jerusalem meeting, Lloyd Fosdick wrote to the chairmen of X3 and SC22 (document 1818) expressing concern that the ISO and ANSI standards for FORTRAN 90 might differ. He received reassuring replies from both, but the ..,announcement of the ANSI public comment period gave different deadlines for comments that might affect the ANSI and ISO standards. Lloyd sent a further letter and was further reassured by phone. Because the features were finalized in 1990, it was decided to call the language FORTRAN 90. The Standard itself was finalized in April 1991 and published as ISO Standard in August. X3 is voting on it. Because there was one NO vote there is to be a reconsideration ballot. The expectation is that the ANSI Standard will be identical to the ISO Standard apart from such things as the title page, headers, and footers. The First compiler was announced (by NAG) in June. Many other vendors are actively working on compilers. John Reid organized a mini-symposium on FORTRAN 90 as part of the ICIAM 91 (see 2.4.1. Despite the high degree of parallelism the session was well attended and lively. Brian Smith and John Reid are writing a paper on the "The advantages of FORTRAN 90" for Computing. There is now a committee called X3H5 that is looking at parallel programming for procedural languages including FORTRAN 77, FORTRAN 90, and C. They use a shared memory model, noting that it may be virtual shared memory, and have some language constructs, synchronization mechanisms, and data distinctions. John's personal view is that their model is not sufficiently simple. These issues are also being considered by Uberkuher, who has written a report. John Reid urged the WG 2.5 to get involved with this issue. ICIAM, 1991 ------------ Document: IFIP/WG 2.5 (Karlsruhe-17) 1817, 3 pages, The Second International Conference on Industrial and Applied Mathematics was held in Washington, D.C., between 8 and 12 July 1991. Three minisymposia were organized by the IFIP WG 2.5 members during ICIAM 1991: - J. Reid, "Fortran 90: How the New Language will Benefit Applied Mathematics." - S. Feldman and M. Vouk, "Scientific and Numerical Computing in C." - H. J. Stetter, "Use of Automatically Derivable Analytic Information in Numerical Computation." All three minisymposia were well attended and well received. Summary of the content of the minisymposia is given in document 1817. Raleigh 1994: ============= Hanson reported on some issues related to FORTRAN 90 and virtual message passing communication libraries PVM and MPI. Hanson will submit a position paper. Hanson presented Reid's proposal on "Enable statement". After some discussion of this proposal, it was decided that Paul and Rice will summarize the various comments and provide input to Reid and WG 2.5 group. The group supports and appreciates very much Reid's efforts. Patras 1998: ============ This project remains very active with Reid and Hanson working on F-- (now Coarray Fortran) and Walter participating in the committee setting the standards for Fortran 2003. Fortran 95 compilers will soon be released and SUN is to release an interval arithmetic package within their F77. Walter pointed out that FORTRAN 2003 will likely introduce a mechanism for calling C programs. In particular there is a plan to set a standard for the FORTRAN to C interface. Purdue 1999: ============ Hanson presented an overview of recent activities in this area. Focus is on reaching consensus or at least agreement on what is to be included in Fortran 2000. Three items under discussion should be of particular interest to our WG. They are interoperability with C (Fortran calls to C programs), floating point exception handling, and interval arithmetic enabling technology. Technical reports have been produced on each topic and more information can be obtained from the website http://www.fortranlib.com/standard.htm. Ottawa 2000: ============ Hanson presented an overview of recent activities in this area. All the technical work has been completed for the next revision of the standard. Exception handling and derived types are being seriously considered and decisions will be made soon. For more information see the website http://www. j3-fortran.org/. Amsterdam 2001: =============== A lively discussion of the status of Fortran and the activities of J3 was led by Walter. The current target date for the next version of Fortran (F2003) is 2004. There was particular concern expressed over the slow progress of J3 decisions in addressing the issues that must be resolved before a new standard is reached. The current focus of J3 is on removing inconsistencies and maintaining supported features in current versions. In the meantime most users seem to be content with using a F77 subset (of F95) while others are programming in C++ or Java (with calls to existing Fortran Libraries). Those members that are concerned about the future versions of Fortran should become actively involved. For more information see the website http : //www.j3-fortran.org/. Portland 2002: ============== Snyder discussed the current draft, now under public review with comments due by next August. The new features to be added were discussed. Of particular interest was the adoption of intrinsic modules for IEEE arithmetic exception handling. Example of things to be considered for future extensions were identified. These included some Object Oriented facilities, some interoperability with C capabilities, and asynchronous I/O. The draft standard can be found at the website `http://www.j3-fortran.org/. Fortran is still be widely used and standards are being developed for future versions. Strobl 2003: ============ Walter presented an overview of the recent developments (since F90/95). The open issues left to be decided before the next standard is adopted (likely to be F2003) were identified and discussed. The new features will make data abstraction and high performance computing more transparent. There will be limited OOP features. Washington 2004: ================ This continues to be a very active project. Van Snyder's recent note concerning the future and current importance was mentioned. It was also noted that John Reid was also revising his Fortran book. Hong Kong 2005: =============== The new Fortran standard was published in November 2004. John Reid has revised his book based on the new standard. Prescott 2006: ============== Brian Smith presented a talk "A Test Harness TH for Numerical Applications and Libraries" at the working conference. Uppsala 2007: ============= This continues to be a very active project with several members participating in the continuing standards meetings. Snyder's technical talk "Fortran 2003 and Beyond" provided an overview of some important recent developments in this area. Snyder agreed to take on the role of the leader of this project and he was asked to consider updating the project description. He also felt it would be helpful if the WG designated him to be the WG representative on the Fortran Standards Committee. The group agreed and Snyder was endorsed as our official representative. Toronto 2008: ============= This continues to be a very active project with several members participating in the continuing standards meetings. Coarrays for parallel processing, Abstract of talk by Van Snyder. ------------------------------------------------------------------ Coarrays were designed to answer the question "What is the smallest change required to convert Fortran into a robust and efficient parallel language?" The answer is a simple syntactic extension. It looks and feels like Fortran and requires Fortran programmers to learn only a few new rules. These rules are related to two fundamental issues any parallel programming model must resolve: work distribution and data distribution. To address work distribution, the coarray extension adopts the single program multiple data (SPMD) model. A single program is replicated a fixed number of times. Each replication, called an image, has its own set of data objects. Each image executes asynchronously, and the normal rules apply. The execution sequences may differ from image to image, with the actual path of each image determined by normal control constructs and explicit synchronizations. Between synchronizations, the compiler can use all its normal optimization techniques, as if only one image were present. The coarray extension addresses data distribution by providing data objects that span the images and means to access them using a syntax very much like ordinary syntax. The new data objects are called coarrays, from which the paradigm gets its name. Coarrays have the important property that as well as having access to the local object, each image may access the corresponding object on any other image. Although coarrays were originally designed as an extension to Fortran, and are included in the 2008 Fortran standard, other languages and language extensions inspired by coarrays are under development. UPC, X10, Chapel, and class libraries being developed for use in C++ all have a conceptual framework similar to coarrays. A complete description is in ftp://ftp.nag.co.uk/sc22wg5/N1751-N1800/N1762.pdf Raleigh 2009: ============= This continues to be a very active project with several members participating in the continuing standards meetings. Snyder gave a presentation at the "IFIP Working Group 2.5 Symposium 2009" on the new features of Fortran 2008, other than coarrays (which were discussed at Toronto in 2008). A complete description of the new features in Fortran 2008 is available from ftp://ftp.nag.co.uk/sc22wg5/N1701-N1750/N1735.pdf and the whole proposed standard is in ftp://ftp.nag.co.uk/sc22wg5/N1751-N1800/N1791.pdf Leuven 2010: ============ Van Snyder made a plea for more members from the user community to join the ISO or ANSI Fortran committees. The Standard Fortran 2008 is expected to be approved and published during 2011. The technical content of the proposal for the Fortran 2008 Standard is now fixed. Boulder 2011 ============ Van Snyder reported 12 July 2011: Fortran development is an active project. An interim document, called "Type 2 Technical Report 29113" will expand the facilities for C interoperability. It is available from ftp://ftp.nag.co.uk/sc22wg5/N1851-N1900/N1866.pdf Plans are underway for a revision to follow the Fortran 2008 standard, but neither requirements nor a target date have been set. Since Fortran 95, most work has been put online. Fortran standards (as final committee drafts) and corrigenda are available at http://ftp.nag.co.uk/sc22wg5/links.html. Members of IFIP WG 2.5 are encouraged to take an active role in future development of Fortran. This continues to be a very active project. Fortran 2008 has now been accepted by ANSI and ISO. Extensions for the next standard are now being considered. These include such things as coarrays. John Reid pointed out the overlapping related concern of WG23 on "Vulnerabilities in programming languages" and that committee has produced a report discussing the issue and giving some examples and fixes. He has made this report N0389 available to the group: http://grouper.ieee.org/groups/plv/ John Reid has also produced a document "Vulnerability descriptions for language Fortran" which is available as http://www.nsc.liu.se/~boein/ifip/intern/Annex.pdf Walter was dropped from the list of active participants. Santander 2012: =============== Van Snyder 21/6: Technical Corrigendum 1 for Fortran 2008 was submitted to ISO for ballot on 12 February 2012. The SC22 ballot ended on 14 May 2012. The ISO/IEC JTC1/SC22/WG5 draft is available at ftp://ftp.nag.co.uk/sc22wg5/N1900-N1950/N1903.pdf. The focus of development during the last year has been on ISO/IEC Technical Specification 29113, "Further Interoperability of Fortran with C" (formerly a "type 2 technical report"). The goals are to support o assumed-shape arguments, o optional arguments, o allocatable arguments, o Fortran pointer arguments, o asynchronous data transfer other than by I/O statements (for example using MPI ISEND), o interoperability with C "void" types, and o rank-independent C arguments associated with contiguous Fortran arguments -- for example to allow passing any rank array to MPI SEND. The 2012 ISO/IEC JTCA/SC22/WG5 Fortran committee meeting, joint with ANSI/INCITS/PL22.3, is to take place in Toronto the week before the 2012 IFIP WG 2.5 meeting. The draft of Technical Specification 29113, to be finalized at that meeting, is available at ftp://ftp.nag.co.uk/sc22wg5/N1900-N1950/N1917.pdf. Work has also proceeded on developing requirements for further features of coarrays. The new features proposed are o Teams, which would allow different parts of a program, for example ocean and atmosphere in a combined circulation model, to operate more independently until interaction is needed. o Collectives, which would provide intrinsic support for operations such as summation across multiple images. o Additional intrinsic atomic subroutines. o Synchronization using events. o Parallel input/output. The current draft of the proposal is available at ftp://ftp.nag.co.uk/sc22wg5/N1900-N1950/N1924.txt. Permission from ISO for an official project has not yet been sought. A draft of a Fortran annex to ISO/IEC Technical Report 24772, "Guidance to Avoiding Vulnerabilities in Programming Languages through Language Selection and Use" has been prepared. It is available at ftp://ftp.nag.co.uk/sc22wg5/N1900-N1950/N1915.pdf. As usual, I renew my plea for Fortran users to join the Fortran committees. The ANSI/INCITS committee is dominated by vendors whose concerns for future development appear primarily to be related to a few large customers. Membership of the ISO committee is more diverse, but less influential. Shanghai 2013: ============== Report by Van Snyder and John Reid: The 2013 ISO/IEC JTC1/SC22/WG5 Fortran committee meeting, joint with ANSI/INCITS/PL22.3, took place in Delft, The Netherlands, during the week of 24-28 June. The coarray facilities of Fortran 2008 should not be overlooked. These facilities are described informally in ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1824.pdf The primary activity was to continue work on further facilities for coarrays, as described in the report to the 2012 Santander meeting. This work is now an official ISO project, ISO/IEC Technical Specification 18508. A post-meeting draft is available at ftp://ftp.nag.co.uk/sc22wg5/N1951-N2000/N1983.pdf ISO/IEC Technical Specification 29113 "Further Interoperability of Fortran with C" has been published. ISO/IEC Technical Report 24772 "Guidance to Avoiding Vulnerabilities in Programming Languages through Language Selection and Use," including a Fortran annex, has been published. XcalableMP or XMP ----------------- Report by Mitsuhisa Sato with comments from Van Snyder Full report "A proposal for PGAS programming languages for numerical software" is available as http://conf.shu.edu.cn/disd2013/ppt/8-5/1-Sato.pdf What is missing for Coarray, for example, collective communications: Teams, events, reductions, atomics, and collectives are being addressed by Technical Specification 18508, which is currently under development. Significant changes were made two weeks ago, during the joint ISO and US Fortran committee meeting. Inter-operability between CAF and UPC, XMP (this is my project): Some of my colleagues say that UPC is very poorly defined, and not very widely implemented. I'm not an expert so I cannot comment on their claims. Modularity/Decomposiability of PGAS program: I don't think this is a problem in Fortran, especially after teams are provided. Performance study of PGAS program. Scalability of one-sided Communication: Unlike MPI, in coarray Fortan, there is no special position for one-sided communication The way that coarray operations are implemented depends on several factors. Among the factors are the compiler that implements it. When the program is running, the processor might dynamically decide whether to use MPI or shmem or something entirely different. This is especially true on a cluster where each node has memory shared among eight or twelve cores. Operations between images on the same node could use shmem, while those between images on different nodes might use MPI. One of the important design goals of coarrays was that the underlying communication method is not prescribed by the design. Additions by Bo Einarsson: ========================== John Reid is working on a new book discussing Co-array Fortran: Robert W Numrich and John K Reid, CoArrays: Parallel Programming in Fortran. It will be published by Chapman & Hall/CRC, hopefully in 2014. The new book by Markus mainly discusses Fortran 2003 and 2008: Arjen Markus, Modern Fortran in Practice, Cambridge University Press, 2012, ISBN 978-1-107-01790-0 (Hardback), ISBN 978-1-107-60347-9 (Paperback) Another new book by Richard J Hanson and Tim Jopkins is "Numerical Computing with Modern Fortran", SIAM 2013, ISBN 978-1-611973-11-2. Vienna 2014: ============ Snyder will consult with John Reid and they will produce an update of the current report that includes references to recent related activities. Halifax 2015: ============= Report by Van Snyder: The ISO Fortran committee (ISO/IEC JTC1/SC22/WG5) will meet in London during the first week of August 2015. The primary objective of the meeting is to finalize the list of new projects for the revision currently under development. Because the technical content will be finalized this year, the revision will be known informally as Fortran 2015. The revision should be submitted to ISO for publication in 2017, and ISO should publish it in 2018. The draft of the standard that will be revised in London is available from http://j3-fortran.org/doc/meeting/207/15-007r1.pdf. An ISO Technical Specification, number 29113, concerning further interoperability with C, was recently completed and published by ISO. It is incorporated into the current draft of the Fortran standard. This is available from ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1942.pdf. A draft of ISO Technical Specification 18508, concerning additional features for parallel programming, has been submitted to the parent committee SC22 for formal voting by countries. What changes will be needed and whether it will be integrated into the current revision of the Fortran standard will be decided in August. The draft is not available directly, but it can be accessed by the link identified as N2056 at http://www.nag.co.uk/sc22wg5/docs.html. Documents: ========== 1. J. Rice, Letter to X3J3, IFIP/WG 2.5 (Stanford-1531) 2. L. Fosdick, Letter to X3J3, IFIP/WG 2.5 (Karlsruhe-1818) 3. J. Reid, Exception Handling in Fortran, IFIP/WG 2.5 (Kyoto-2207) Sydney 2018: ============ Report by Van Snyder: The revised Fortran standard is essentially finished, and should be published in 2018. The traditional naming scheme for Fortran has been to indicate the version of the standard according to the year that technical content was frozen. For the present revision, that was 2015. The INCITS and ISO Fortran committees decided to follow the nomenclature used by other programming language standards, and denote the next standard using instead the year of publication. Therefore, the next standard will be known as "Fortran 2018" (assuming ISO manages to publish in 2018). The two major projects of the 2018 revision are further interoperability with C, and further coarray features. These were both developed as Technical Specifications, which (theoretically) have development schedules independent from the main standard. Both reports were approved and published, and have been incorporated into the draft 2018 revision. Fortran 2003 provided support for interoperability of Fortran objects for which directly corresponding entities exist in C. In Fortran, objects that are allocatable or pointers, or dummy arguments that are optional or have assumed shape, were important additions. They have no counterpart in C, and were not addressed by Fortran 2003. The Fortran 2018 standard defines C descriptors to use these objects within C functions. Many parallel programs have parts that can work independently for a time, but that contain significant internal interaction. One obvious example is a combined ocean-atmosphere circulation model. To provide support for these kinds of problems, "teams" have been added to coarrays. When teams have been formed, and subsets of the images have chosen the teams to which they belong, image indices are measured separately within each team, and collective activities such as synchronizations by default apply to the team, not the entire program. This simplifies program development, and integration of formerly separate programs into a single program. Numerous small projects were also completed, and are enumerated in the introduction of the revised standard. 2020 (online): ============== Update by Van Snyder received on 16-8-2020 ------------------------------------------ The 2018 revision of the Fortran standard is complete. The committees had been using the year the technical content was completed in the name. The committees agreed that the present and future revisions will be referenced by the year of publication, so it will be informally known as "Fortran 2020." The official designation will be ISO/IEC 1539-1 (2020). The two Technical Specifications referenced in the 2015 Halifax report were incorporated. The document submitted to ISO for publication is available from https://j3-fortran.org/doc/year/18/18-007r1.pdf. It is identical to the one that the committees will use as the reference work for corrigenda, except the ISO publication will not have line numbers. The Introduction describes the changes from the previous revision. Work is underway to develop the next revision, targeted for publication in 2025. 2023 (Amsterdam): ================= Update by Van Snyder received on 23-2-2023 ------------------------------------------ The 2023 revision of the Fortran standard is complete. This is a minor revision. The Fortran committees are now using the year in which ISO publishes the standard, rather than the year in which technical content is frozen, to designate the revision. Although there is a remote chance that ISO will publish in 2024, it is likely that this revision will be known as Fortran 2025. The draft for balloting is available at https://j3-fortran.org/doc/year/23/23-007.pdf. The only significant difference between this document and the one that will be published by ISO is that ISO prohibits line numbers. The more significant revisions include: o The maximum length of a line in free source form has been increased to ten thousand characters. The limit on the number of continuation lines has been removed. This is primarily useful for programs that generate Fortran code, or in applications that require large amounts of named constant array data such as tables of chemical, nuclear, or material properties. Fixed source form is unchanged. o New intrinsic trigonometric functions' arguments can be specified in degrees or multiples of pi, and the results of inverse trigonometric functions can be produced in degrees or multiples of pi, for example SIND, SINPI, ASIND, and ASINPI. o The IEEE modules are completely compliant with IEEE-754 (also known as ISO/IEC 60559:2020). o A decision-making structure has been added within expressions, essentially an "if then else" structure, but spelt using ( expr ? expr : expr ). An additional form consisting only of ( expr ? expr ) can be used as an actual argument that corresponds to an optional dummy argument to compute whether it is present. This is useful, for example, with procedures that evaluate a function and its derivatives with respect to several parameters, e.g. temperature, pressure, frequency, ..., and the desire to compute them is determined by input or other computations. Before this, one needed a "combinatorial explosion" of "if then else if else if else if ... endif" with 2^n branches for n optional arguments. o Support for object-oriented programming has been improved. o Support for concurrent programming using COARRAYS has been improved. o A new concept of "rank independent" data references has been introduced ("rank" is the Fortran term for the number of declared dimensions of an array, not the mathematical definition of the rank of a matrix). For example, one can use a one-dimensional array having the same length as the rank of another array to specify subscripts. The complete list of revisions to the previous standard is included in the Introduction.