Fortran 90(ID:1627/for050)

Previously Fortran 8x, Fortran 88  and Fortran Extended.

An extensive and rationalised superset of FORTRAN 77, with the stated purpose "promote portability, reliability, maintainability, and efficient execution... on a variety of computing systems". To allow for the preservation of existing bodies of code, all of the F77 language was included, but several features were labelled "obsolescent".

Derived types, assumed shape arrays, array sections, functions returning arrays, case statement, module subprograms and internal subprograms, optional and keyword subprogram arguments, recursion, and dynamic allocation.

ISO 1539:1991

Structures:
Related languages
ALGOL 60 Revised => Fortran 90   Influence
FORTRAN 77 => Fortran 90   Evolution of
Fortran 8x => Fortran 90   Renaming
Fortran Extended => Fortran 90   Renaming
Fortran 90 => Fortran 95   Evolution of
Fortran 90 => Fortran D   Augmentation of
Fortran 90 => Fortran-Linda   Evolution of
Fortran 90 => Fortran-XSC   Extension to
Fortran 90 => HPF   Augmentation of
Fortran 90 => Vienna Fortran   Extension of
References:
  • Brainerd, Walter S. "Programmer's guide to Fortran 90" Intertext Publications, Inc July 1990 view details
  • Meek, Brian "The Fortran (not the foresight) saga: the light and the dark" pp23-32 view details External link: Extract: Fortran Standards
    Week by week we read about corporate battles for shares in a market, be it hardware, software or services, about takeover manoeuvrings and buyouts, about rival consortia seeking to dominate areas like Unix or networking. Yet these ongoing stories, hard though they may sometimes be to follow, have the complexity of a Ladybird book, compared with the long-running saga of the Fortran 8X standard.

    The story began immediately after the finalisation of the Fortran 77 standard, hence predating the Thatcher era - and it could still outlive it. No longer is it the "8X" story, of course; the US Fortran Standards Committee is now calling it "Fortran 90", but considering it started as "82" and for a period of false dawn was "88", no-one who has survived the whole saga to date would put serious money on that being the final designation. (However, those who remember a novel called "Limbo 90" may regard it as not inappropriate.)

    One day someone perhaps will record the history of Fortran 82/8X/88/90/..., but it needs an Escher to depict it or a Borges to describe it. Indeed, Borges, Borgias and Byzantium all come to mind when one looks at the complex, multi-layered interplay of forces which have contributed. The best that can be done here is to indicate the various forces and their interconnections, and briefly describe the issues and forces involved in the main battles that have occurred.

    The main groups of forces are the standards committees, corporate bodies, professional institutions, and individuals. These themselves have subgroupings and classifications.

          in Fortran Forum 9(2) October 1990 view details
  • Metcalf M. et al, "Fortran 90 Explained", Oxford University Press 1990. view details
          in Fortran Forum 9(2) October 1990 view details
  • Adams, J. C. (1992). Fortran 90 handbook : complete ANSI/ISO reference. New York, Intertext Publications : McGraw-Hill Book Co. view details
          in Fortran Forum 9(2) October 1990 view details
  • Adams, Jeanne C. et al "Fortran 90 handbook: complete ANSI/ISO reference" Intertext Publications, Inc.,/McGraw-Hill, Inc. March 1993 view details
          in Fortran Forum 9(2) October 1990 view details
  • Adams, Jeanne "Controversy, compromise, modernization: From FORTRAN to Fortran 90" SCD Computing News, Summer 1994. Copyright 1994 University Corporation for Atmospheric Research view details External link: online copy
          in Fortran Forum 9(2) October 1990 view details
  • Levine, David "Fortran language extensions" pp11-27 view details Abstract: Current Fortran 90 implementations support a large number of extensions to the Standard language, most of which originated prior to F90. A great many user programs require at least some extensions. The "Implementations" Subgroup of X3J3 discussed the possibility of informally assembling some documentation of these extensions. External link: Online copy
          in Fortran Forum 13(4) December 1994 view details
  • Brainerd, Walter S.; Adams, J. C. "Programmer's Guide to FORTRAN 90" 2nd ed Springer-Verlag New York, Inc October 1995 view details
          in Fortran Forum 13(4) December 1994 view details
  • Chamberland, L. (1995). Fortran 90 : a reference guide. Upper Saddle River, NJ, Prentice Hall PTR. view details
          in Fortran Forum 13(4) December 1994 view details
  • Meissner, Loren P. "FORTRAN 90" PWS Publishing Co. Boston, MA, USA 1995 view details Abstract: Meissner, in his book Fortran 90, presents FORTRAN programming in the context of using the language as a tool for solving engineering or scientific problems. Students need to know which FORTRAN language features are more important/useful than others, and Meissner's explanations give students a good overview of key ideas. Meissner motivates his presentation of FORTRAN specifics through examples that show how the FORTRAN feature being discussed is used in the context of mathematical, scientific or engineering related problems (i.e. Fibonnaci sequence, factorials, Newton's Method, trigonometric functions, statistics, isotopes, polar form).  

          in Fortran Forum 13(4) December 1994 view details
  • Redwine, C. Upgrading to Fortran 90. New York, Springer 1995 view details
          in Fortran Forum 13(4) December 1994 view details
  • Adams, Jeanne and Brainerd, Walt "A little history and a Fortran 90" view details Abstract: Some of the history of the development of the Fortran language is presented, from a de facto standard early in the 1950s at IBM to the major revision that Fortran 90 represents. The article concludes with a short description of the major features of the language. External link: Online copy
          in Computer Standards & Interfaces (Fortran 90 Issue) 18(4) August 1996 view details
  • C. D. Norton, V. K. Decyk, and B. K. Szymanski "On Parallel Object Oriented Programming in Fortran 90" ACM SIGAPP Applied Computing Review, 4(1):27-31, Spring 1996. view details External link: Online copy
          in Computer Standards & Interfaces (Fortran 90 Issue) 18(4) August 1996 view details
  • Delves, L.M.; Lloyd, D. and Lahey, T. "Fast forwarding Fortran, Part 1: Clean Fortran" view details Abstract: Fortran 90 represents an important advance in language design for scientific and engineering computing, and will we believe be widely used. However, a number of language facilities widely regarded as useful, still are absent from Fortran 90. Others, widely regarded as adding nothing but irregularity to the language, remain part of it, and their continued existence makes the addition of new features more difficult. And yet, the weight of existing code makes deletion of these features from the ISO standard a difficult and slow process. In this paper we discuss a version of Fortran 90 which we refer to as Clean Fortran. It contains a number of restrictions to the current language. The restrictions are made to remove irregularities. The resulting language is intended to form a base from which much-needed language extensions can be more readily incorporated. We discuss also a way in which Clean Fortran, or some agreed variant of it, can be readily incorporated into the current language evolution cycle by re-introducing a Subset Fortran language. External link: Online copy
          in Computer Standards & Interfaces (Fortran 90 Issue) 18(4) August 1996 view details
  • Du Croz, Jeremy "Designing numerical libraries in Fortran 90" view details Abstract: Currently Fortran 77 is the most widely used language for libraries of numerical procedures, although it has many disadvantages for this purpose. Fortran 90 offers significant benefits for both developers and users of numerical libraries, especially: explicit interfaces, dynamic allocation of workspace, assumed-shape arrays, optional arguments, generic interfaces, parameterisation of precision, and derived types. All these features help to simplify the user-interface to procedures. Fortran 90 libraries can be constructed as a hierarchy of modules, with controlled access to entities, which may include type definitions and named constants as well as procedures. The interfaces to procedures may also be defined in terms of operators. Numerical libraries in Fortran 90 are already available from two commercial vendors, NAG and VNI, and numerical software in Fortran 90 has begun to appear in the public domain. External link: Online copy
          in Computer Standards & Interfaces (Fortran 90 Issue) 18(4) August 1996 view details
  • Kelble, Richard "Fortran 95 and beyond" pp309-314 view details Abstract: This article discusses the plans for the future evolution of the Fortran Language. The topics covered are: 1) The process that will govern the future revisions of the standard; 2) Some of the history of the development of that process; 3) The evolution of the Fortran 95 feature set; 4) A description of the features included in Fortran 95; 5) The beginnings of the Fortran 2000 feature set; and 6) Information on the submission of requirements for a future revision. External link: Online copy
          in Computer Standards & Interfaces (Fortran 90 Issue) 18(4) August 1996 view details
  • Martin, Jeanne T. "The growing international influence on Fortran standardization" pp321-322 view details Abstract: Fortran was the first programming language to be standardized. That standardization effort was initiated and completed within the United States, resulting in the 1966 standard. Today, standards in the field of information technology are truly international standards. This article describes how Fortran standardization made that transition. External link: Online copy
          in Computer Standards & Interfaces (Fortran 90 Issue) 18(4) August 1996 view details
  • Metcalf M. and J.Reid, FORTRAN 90/95 Explained, Oxford University Press, Oxford, 1996. view details
          in Computer Standards & Interfaces (Fortran 90 Issue) 18(4) August 1996 view details
  • Metcalf, Michael "Abstract data types in Fortran 90" pp349-359 view details Abstract: Progress in programming languages has been marked by successive waves of new techniques, each accompanied by miraculous claims from its proponents. Only after a certain time lag do these techniques become standardized. The functionality required to support one of these techniques, abstract data types (ADTs), is now part of the latest Fortran standard, but the newest wave is object orientation (OO). This paper describes the implementation of ADTs in Fortran and speculates on whether the language will withstand the OO onslaught. External link: Online copy
          in Computer Standards & Interfaces (Fortran 90 Issue) 18(4) August 1996 view details
  • Muxworthy, David "Language architecture ? obsolescence and deletions" pp303-307 view details Abstract: As languages develop, they typically acquire new features which may make existing features redundant; this tends to make the language, including its processors and documentation, unnecessarily large. This paper describes the model adopted in Fortran for purging unwanted, redundant facilities and describes those features of Fortran 90 which are not present in Fortran 95, and why. Further it describes, with reasons, the features which may be deleted in the definition of Fortran 2000. It is however stressed that it is open to any vendor to continue to provide ?deleted? features which a minority of its customer base might need. External link: Online copy
          in Computer Standards & Interfaces (Fortran 90 Issue) 18(4) August 1996 view details
  • Norton, Charles D. "Object Oriented Programming Paradigms in Scientific Computing" Doctoral Dissertation, Rensselaer Polytechnic Institute, August 1996 view details
          in Computer Standards & Interfaces (Fortran 90 Issue) 18(4) August 1996 view details
  • Page, Rex L. "Procedures and modules in Fortran 90" pp333-347 view details Abstract: No new feature in Fortran 90 is more important than modules for the support of effective software engineering methods. Fortran 90 modules make it possible to encapsulate portions of software: to make entities accessible only from those parts of a program in which the software designer desires and plans for their accessibility. Programmers can control the visibility of software entities (variables, procedures, data types, etc.) from the site of declaration (with PUBLIC/PRIVATE specifications) or from usage sites (with USE-ONLY specifications), and these entities can be packaged together in units for convenient and safe access throughout an application. In this way, Fortran 90 modules fully support the concept of data abstraction, one of the most important organizing principles of software design. This paper illustrates the use of modules to create a package of signal processing functions. It discusses the use of explicit interfaces defined in modules or interface blocks to improve the type safety of Fortran code, user-defined generic procedures and operators, specification of the intended use of procedure arguments (INTENT IN, OUT, and INOUT), dummy-argument arrays that inherit their shape from actual arguments, local arrays with shapes that depend on procedure inputs, recursion, optional and keyword procedure-arguments, and functions that deliver arrays or structures as values. The paper is not comprehensive. Topics omitted include internal procedures, statement functions, multiple entry, alternate return, and pointers, and little is said about the large collection of intrinsic procedures in Fortran 90. All of the illustrative code follows a programming method based on formulas and equations rather than step-by-step procedures. In this method, known as functional programming, names are defined only once; their associated values are never replaced with new ones. Fortran 90 facilitates the use of this method by permitting the definition of functions whose values are arrays or structures and by allowing functions to invoke themselves. External link: Online copy
          in Computer Standards & Interfaces (Fortran 90 Issue) 18(4) August 1996 view details
  • Reid, John "The array features" pp323-331 view details Abstract: The array features were never controversial during the development of Fortran 90 and were extensively used on massively parallel computers in advance of the finalization of the standard. In this paper, these features are described and the reasoning behind particular choices is explained. DOI
          in Computer Standards & Interfaces (Fortran 90 Issue) 18(4) August 1996 view details
  • Schonfelder, J.L. "Technical deficiencies with Fortran 90" pp295-302 view details Abstract: A personal view of the major technical deficiencies of Fortran 90 is presented. The defects are listed and described in what might be interpreted as a set of requirements for a future language revision. The list reflects the view of one of the active designers of Fortran 90 and one who is the head of a major academic computing service whose users are slowly becoming significant users of Fortran 90. The views are therefore conditioned both by individual observations and by the observed reactions of users starting to use Fortran 90 in anger. External link: Online copy
          in Computer Standards & Interfaces (Fortran 90 Issue) 18(4) August 1996 view details
  • Wagener, Jerrold L. "High performance Fortran" view details Abstract: Fortran 90 provides ideal language support for data parallelism in the form of concurrent array operations. To achieve high efficiency in a massively parallel environment, however, arrays must be optimally distributed over the processing elements. High Performance Fortran is an extension of Fortran 90 that allows such optimum distributions to be specified in cost-effective and portable manner. This paper briefly describes basic parallel architectures and programming paradigms, and sketches the nature of High Performance Fortran. External link: Online copy
          in Computer Standards & Interfaces (Fortran 90 Issue) 18(4) August 1996 view details
  • Decyk, V. K.; Norton, C. D. and B. K. Szymanski "Expressing Object-Oriented Concepts in Fortran 90" ACM Fortran Forum, vol. 16, num. 1, pp. 13-18, April 1997. view details
          in Computer Standards & Interfaces (Fortran 90 Issue) 18(4) August 1996 view details
  • Forsythe, C. (1997). Contemporary computing for engineers and scientists using Fortran 90. Boston, PWS Pub. Co. view details
          in Computer Standards & Interfaces (Fortran 90 Issue) 18(4) August 1996 view details
  • Meissner, Loren P. "Essential FORTRAN 90 and 95: Common Subset Edition" Unicomp, Incorporated 1997 view details
          in Computer Standards & Interfaces (Fortran 90 Issue) 18(4) August 1996 view details
  • V. K. Decyk, C. D. Norton, and B. K. Szymanski "How to Express C++ Concepts in Fortran 90" Scientific Programming, 6(4) Winter 1997 pp363-390 view details Abstract: This paper summarizes techniques for emulating in Fortran90 the most important object-oriented concepts of C++: classes (including abstract data types, encapsulation and function overloading), inheritance and dynamic dispatching. External link: Online copy Extract: Introduction
    Introduction
    Object-Oriented Programming (OOP) has proven to be a useful programming
    paradigm for complex programs, especially those modeling ?real world problems.?
    The scientific community has been slower to adopt this paradigm, but even here OOP
    is beginning to draw a following and even more curious interest. There are a number
    of reasons for this reticence in the scientific community. One reason is that many
    scientists who write modest-sized programs for their own needs, are comfortable using
    Fortran77 and C, and see no reason to change. Others with more complex programs
    written in Fortran have a great deal invested in their legacy codes and do not want to
    switch to a new programming language because of the threat to this investment.
    Adopting OOP means not only learning a whole programming style, but learning a
    new and unfamiliar language as well. The dominant OO language in the scientific
    community, C++, is very complex and requires a substantial investment of time to learn
    how to use effectively. In using C++, there are also concerns about reported poor
    performance, lack of language and compiler standardization, and lack of standard
    class libraries for scientific computing. Although many of these concerns are being
    addressed by the C++ community, the scientific programmer may not know how to
    evaluate the current situation. Finally, many people have no clear idea of how their
    scientific productivity will improve by using OOP.
    Fortran90 is a modern programming language with many new features which
    appear to be useful for OOP. Since it is known that OOP is possible in non-OOP
    languages [1], we decided to test the capabilities of Fortran90 by translating published
    examples of C++ code from textbooks and journal articles. We discovered that almost
    all the features of C++ could either be translated directly or emulated without great
    effort. The major exception was dynamic binding, emulation of which required more
    effort. As a result, we feel that it is practical to adopt OOP principles in Fortran90.
    Since Fortran90 is backward compatible with Fortran77, this gives a migration path for
    evolving toward a new programming style in an incremental fashion. OOP in both
    Fortran90 and C++ requires applying a methodology and non-OOP programs are
    possible in either language. However, OOP in Fortran90 requires more self-discipline.
    These techniques are useful even if the ultimate goal is to convert a Fortran legacy
    code to C++. Experience has shown that it takes a year or more to convert a typical
    scientific code to C++. This is a long time for a scientist to be non-productive.
    Converting to an OO-style in Fortran90 is much faster and the code can be in continual
    productive use in the meanwhile. The final step in moving from Fortran90 to C++ is
    much easier if the classes and objects are already clearly understood.
    This paper is also of interest to those who need to work in an environment where
    Fortran90 and C++ are both used. Knowing how to translate concepts between the
    languages has proved useful to us in merging Fortran90-based scientfic codes with
    graphics libraries and utility libraries for adaptive mesh refinement written in C++. If
    advanced features of Fortran90 are used, it is much more challenging to merge
    Fortran90 and C++ than it is to merge Fortran77 and C. Understanding which features
    of C++ are difficult to emulate and which are not is also useful in determining which
    language should be used for which part of a complex project.
    2
    Finally, it has been determined that Fortran2000 will be fully object-oriented. New
    language features will be added for inheritance and run-time polymorphism, while
    retaining existing language mechanisms for other OO concepts. The techniques
    described here can be useful as temporary bridges between the non-OO Fortran77
    and the fully-OO Fortran2000.
    This paper summarizes the techniques we have developed for implementing C++
    concepts in Fortran90. It is assumed that the reader has at least a passing familiarity
    with the concepts of C++, but not necessarily with Fortran90. For readers unfamiliar
    with C++, there are many textbooks available. One that we have found useful is
    Lippman?s [2]. For a more extensive explanation of Fortran90, we recommend the
    book by Ellis et. al. [3] For those who are not familiar with either C++ or Fortran90, we
    recommend our earlier introductory article [4]. We shall illustrate many of our ideas by
    using the extended example of a database application which is described by
    Henderson and Zorn [5] and is used as a benchmark for object-oriented languages.
    For pedagogical reasons, we have simplified and slightly modified their original code.
    The reader may wonder why a non-scientific example was chosen to illustrate
    programming principles of interest to scientists. First, by picking a standard objectoriented
    benchmark, experts in OOP would not have difficulty recognizing that OOP
    was possible in Fortran90. The second reason was to keep the example as simple
    and general as possible.
    For the scientific programmer, the personnel database discussed here serves as a
    model or paradigm for a collection of more complex objects relevant to some scientific
    problem. For example, instead of students and teachers, plasma physicists could think
    of collections of different kinds of particles which require different integration schemes,
    such as electrons with full dynamics, unmagnetized ions, or gyro-kinetic particles
    integrated with a drift approximation. If the particles share some common code, along
    with additional code specific to each particle type, than the personnel database
    corresponds to managing collections of such particles in a multi-species plasma
    simulation. For electrical engineers, instead of students and teachers, one could
    imagine managing collections of adaptive mesh types for electromagnetic
    calculations, where different mesh types are used in different regions of the
    calculation. Since we are focussing on programming techniques here, we thought that
    picking a complex example from plasma physics or electromagnetics would have
    distracted the reader and made the paper more difficult for those unfamiliar with the
    specific scientific area.
          in Computer Standards & Interfaces (Fortran 90 Issue) 18(4) August 1996 view details
  • C. D. Norton, V. K. Decyk, and J. Slottow :Applying Fortran 90 and Object-Oriented Techniques to Scientific Applications" Workshop on Parallel Object-Oriented Scientific Computing at the 12th European Conference on Object-Oriented Programming (ECOOP), Brussels, Belgium. Springer LNCS Series, 1998 view details
          in Computer Standards & Interfaces (Fortran 90 Issue) 18(4) August 1996 view details
  • Decyk1, Viktor K.; Norton, Charles D. and Szymanski, Boleslaw K. "How to Support Inheritance and Run-Time Polymorphism in Fortran 90" Computer Physics Communications 115 (1998) 9-17. view details Abstract: Fortran 90 does not support automatic inheritance and run-time polymorphism as language mechanisms. This paper discusses techniques for software emulation of inheritance and polymorphism in Fortran 90, which simplifies the implementation of an object-oriented programming style in Fortran 90. Extract: Introduction
    Introduction

    In recent years, a number of papers have appeared discussing Fortran 90 and Object-Oriented Programming (OOP) [1-6]. Fortran 90 clearly has some language features which are useful for OOP (derived types, modules, generic interfaces), but clearly lacks some others (inheritance, run-time polymorphism). Is OOP possible or practical in such a situation? Cary et. al. [5] believe that Fortran 90 allows it "to some degree," but that an object hierarchy cannot be constructed and polymorphic types are not possible. Gray and Roberts [6] argue that inheritance can be "faked" (sic), but the effort required too much duplication of code to be practical. In this paper we will show how to emulate inheritance and polymorphic types by software constructs without duplication of code. This allows one to implement all the important concepts in OOP, but with more effort than would be required in an object-oriented language. To keep the exposition of this paper clear and focused, we will expand on the stopwatch example used by Gray and Roberts.

    What is inheritance? Gray and Roberts quote Rumbaugh [7] in defining inheritance to be "sharing of structure and behavior among classes in a hierarchical relationship." They also define polymorphism to be "differentiation of behavior of the same operation on different classes." In many object-oriented languages, inheritance and run-time polymorphism use the same language mechanism so these concepts are glued together. Since Fortran 90 does not have such a unifying mechanism, it is helpful to keep these concepts separate while developing emulation techniques. Another useful distinction is the difference between static (ad hoc) and run-time polymorphism. Static polymorphism means that the actual type being used at any point in the program is known at compile time, while run-time polymorphism means that a single type can refer to one of several possible actual types, and only at run-time can the correct type be determined.

    When Gray and Roberts "fake" inheritance with their stopwatch example, they appear to conflate the concepts of inheritance and polymorphism together. This results in a situation where "developers of new classes derived from the stopwatch class must modify the base stopwatch class to accommodate the new type," and where developers "must duplicate identical code in each of the child classes in order to allow future classes to override the default behavior." Our techniques for implementing inheritance allow us to avoid these difficulties and replace the pejorative "fake" with the more neutral "emulate." pdf
          in Computer Standards & Interfaces (Fortran 90 Issue) 18(4) August 1996 view details
  • Metcalf, M. and J. K. Reid (1999). Fortran 90/95 explained. Oxford ; New York, Oxford University Press. view details
          in Computer Standards & Interfaces (Fortran 90 Issue) 18(4) August 1996 view details
  • Library of Congress Subject Headings F28 view details
          in Computer Standards & Interfaces (Fortran 90 Issue) 18(4) August 1996 view details
    Resources