Fortran 8x(ID:2758/for072)Interim name for Fortran 90Interim name for FORTRAN 90 Related languages
References: in Fortran Forum 1(1) July 1982 view details Many of the points concern an attention to the precise details of the Fortran 77 standard. While conformity is laudable, the degree which Metcalf proposes as desirable seems extreme and unnecessary. Three of the points outlined below must be regarded as requiring "extensions" to the standard. While not having met with a very wide range of compilers, my experience is that most GOOD compilers are a much more flexible than the basic standard, and will accept the extensions suggested. This relaxation may be due to the pressures of the real world, but is definitely in the current spirit of the continuing evolution of Fortran. As far style is concerned, I am sure that the last word has NOT been said. Much depends on personal preference. Some of the following reflects my own preferences to some degree, although many of the points would seem to have wide support. Rather than relist all the points in Metcalf's article, which would take up too much space, I will extract only those of importance. This includes both those to which I object and those which I support strongly. in Fortran Forum 3(3) December 1984 view details in Fortran Forum 3(3) December 1984 view details Control Statements and Other Syntactic Sugar Fortran has a weak set of control statements. Recently, with the Fortran 77 standard an IF, THEN, ELSE construct was introduced. If the trend continues, every ten years or so we will see additional control constructs added to the language. Control constructs of whatever flavor desired are, however, available in a wide variety of other languages. In the 70"s (and perhaps the 60"s) enough work on control structures had been done to allow a number of preprocessing compilers to be produced which use Fortran as the target language. The idea, is that most of the source is passed through to the Fortran compiler, but some statements are captured by the preprocessor and translated into Fortran. Thus, all of the needed control statements are easily translated into quite acceptable Fortran (in fact, almost the same as if hand-coded). Two examples of these preprocessing compilers are RATFOR(2) and IFTRAN(6). Both languages, for indeed they should be viewed as different from Fortran, offer many features: * Free format line * INCLUDE file into source * FOR, DO, WHILE, REPEAT...UNTIL, etc., loops * BREAK out of a loop * NEXT iteration of a loop * IF...ELSEIF...ELSE... conditional logic * CASE statement * RETURN expression * Semicolon as statement terminator It is my recommendation to the Fortran 8X committee that the subject of control structures be put aside until the topics discussed below are addressed and resolved. Extract: Data Abstraction Data Abstraction Fortran was originally intended to translate mathematical formulas into executable machine code. Today computers process information in a variety of forms. The data base aspects of many of our software projects ,cause us to create abstractions of information by using many data types. Currently Fortran has no way of aggregating multiple data types into a manipulatable object. Therefore, we need to introduce into Fortran a structure concept similar to the structure of "C', or a record concept as in Pascal. Furthermore, we must be able to form multi-dimensional arrays where each element in the array is a structure. Data types available in Fortran are also deficient. There should be ways to deal with quantities that are single bits, or fields of bits (adjacent string of bits), eight, sixteen, and thirty-two bits in length. We should be able to do integer operations (both arithmetic and logical) on all the sizes mentioned above as well as to create storage and do assignment operations. It is also useful at times to treat all of the above quantities as unsigned integers, particularly on machines with memory width constraints. As a footnote, there should be two lengths of floating point variables available. An important data type for today's work is a string of characters. One should be able to declare a string with or without an initial content. One should be able to declare an array of strings. Manipulation of strings should be efficient with respect to time and include concatenation, matching, and splitting of strings. A character should be just an eight bit signed or unsigned integer. One must be allowed to manipulate it without tricks. Current Fortrans seems to think a character is something "special". Extract: Referential Aids Referential Aids It is not possible as a Fortran programmer to write a reasonable free storage allocator. Real time programs often need to share memory with one another. One way to do this is to share a large array. Another way would be to associate an area of memory with an array describer at run time. The latter has the important benefit of allowing a Fortran compiler to treat the array as a complex structure for one use of a particular piece of memory and as another structure during another time period in some other portion of the program. An array in many Fortrans is represented in the compiled code by a literal constant (or a special cell) which is equal to (or contains) the address of the first (zeroth) location of the array. By inventing the syntax and semantics to allow declaring a referential array and setting an address into the referential array descriptor we would allow for dynamic storage allocation. The only additional machinery would be a mechanism for obtaining an address. This could take on several forms from compile time (link time) acquisition of static array addresses or end of program to end of memory allocation address to dynamic calculation of the address of a structure in an indexed array. The latter example would be useful in a database application where an array is used to hold a structure of data (i.e., the ith element is a composite entity). Returning a referential value which is stored in a structure descriptor by the caller would allow the calling routine direct access to elements of the structure. Extract: Information Hiding Through Selective Name Supression Information Hiding Through Selective Name Supression Fortran routines have two sources for variables: local declarations and common declarations. Using common declarations to share information does allow a higher efficiency of use of the CPU with the drawback that any part of the program can manipulate the data. Sometimes that is desirable. Often, however, a variaable is used only to communicate within a small set of routines contained in a module. In this case, it is not desirable for all routines in the program to he able to manipulate the variable. Suppose a module contains more than one routine, they share data which are not public data, and a module is packaged in a single compilation unit. A program is then composed of several modules which are linked together (not compiled). The interconnectivity of the modules is then limited to global data, routine calls, and argument lists. The global data and routine name sets should be as small as practical. I propose two ways to reduce these sets. The first suggestion is to create a mechanism to allow a variable (parameter, array, structure, etc.) name to be global over a module (file) but unknown elsewhere. This could be accomplished by placing the declaration at the beginning of the file before the first routine. Each of the subsequent routines would then be allowed to "know" the names, but the compiler would not make the names public. A variant of this suggestion is to allow the programmer to declare whether the variable should be made globally known outside of the module. Another variant would be to allow insertion of module globals between routines which would be known only after their declaration point. The second suggestion to reduce the set of global names is to allow the name of a routine to be known only within a module (compilation unit). This is a bit harder to implement, particularly if the routine which is not to be globally known is declared after its first use (linking is harder). A more positive way to state this idea is that each module has one or more entry point routines. Any additional routines in the module are considered the private business of the module. Both the module global and the module routine ideas would enhance the ability of a programmer to change the implementation of an abstraction as long as the entry points do not change. It is possible to implement module globals with named common, but there remains the chance that some other module would "look" at the named common. in Fortran Forum 3(3) December 1984 view details Array Operations Computation involving large arrays is an extremely important part of engineering and scientific uses of computing. Arrays may be used as atomic entities in Fortran 8x, and operations for processing whole arrays and sub-arrays (array sections) are included in the language for two principal reasons: (I) these features provide a more consise and higher level language that will allow programmers to more quickly and reliably develop and maintain scientific/engineering applications; (2) these features can significantly facilitate optimization of array operations on all computer architectures. The Fortran 77 arithmetic, logical, and character operations and intrinsic functions are extended to operate on array-valued operands. These include whole, partial, and masked array assignment, array-valued constants and expressions, facilities to define user-supplied array-valued functions, and new intrinsic functions to manipulate arrays, extract general sections, and to support extended computational capabilities involving arrays (e.g., array reduction). Extract: Numerical Computation Numerical Computation Scientific computation is one of the principal application domains of Fortran, and the guiding objective for all of the technical work is to strengthen Fortran as a vehicle for implementing scientific software. Though nonnumeric computations are increasing dramatically in scientific applications (and a number of the tentative additions to Fortran reflect that trend), numeric computation remains the workhorse. Accordingly, proposed additions include portable control over numeric precision specification, inquiry as to the characteristics of numeric information representation, and improved control of the performance of numerical programs. Extract: Derived Data Types Derived Data Types "Derived data type" is the term given to that set of features in Fortran 8x that a11ows the programmer and package writer to define arbitrary data structures and operations on them. Data structures are user-defined a~regations of intrinsic and derived data type fields. Intrinsic operations on structured objects include comparison, assignment, input/output, and use as procedure arsumenus. The derived data type facilities may be used, without further operation definition, as a simple data structuring mechanism. With additional operation definitions, derived data types provide an effective implementation mechanism for data abstractions. Procedure definitions in Fortran 8x may appear internally in a program unit, and as such may be used to define operations on derived data types. Internal procedures take essentially the same form as external procedures, with additional provisions for their use as infix operators. New operator symbols may be defined, and the intrinsic operator symbols say be overloaded for use with new data types. Internal procedures may be used simply as a mechanism for defining procedure packages (whether or not new data types are involved), and may be used for new operations on objects of intrinsic data types. Extract: Modular Definitions Modular Definitions There is no way in Fortran 77 to define a global data area in one place and have all the program units in an application use that definition. In addition, the ENTRY statement is awkward and restrictive for implementing a related set of procedures, possibly involving common data objects. And finally there is no means in Fortran by which procedure definitions, especially interface information, may be made known locally to a program unit. All of these deficiencies, and more, are remedied by a new type of program unit that may contain any combination of data element declarations, derived data type definitions, procedure definitions, and procedure interface information. This program unit, called a MODULE, may be considered to be a generalization of and replacement for the BLOCK DATA program unit. A module may be referenced by any program unit, thereby making the module contents available to that program unit. This provides vastly improved facilities for defining global data areas and procedure packages. It also provides a convenient mechanism for encapsulating derived data type definitions (including operations defined on them), i.e., for encapsulating data abstractions. Extract: Deprecated Features Deprecated Features With the advent of superior facilities, the use of certain older features of Fortran should be discouraged, and some of these features should possibly eventually be phased out of the language. For example, the numeric facilities a11uded to above provide the functionality of DOUBLE PRECISION; with the new array facilities non-conformable argument association (such as passing an array element to a dummy array) is unnecessary (and in fact is not useful as an array operation); BLOCK DATA units are obviously redundant and inferior to modules. It is the current intent to identify such "superseded" facilities as deprecated (according to Webster: "mild or regretful disapproval; lower estimated value") features. Deprecated features will remain part of Fortran 8x; it is the intent that complete upward compatibility be maintained between Fortran 77 and Fortran 8x. Deprecated features may, however, be candidates for removal from the version of the Fortran standard following Fortran 8x. It is the intent that in this way official notice is given many years prior to removing a feature from the standard language. In Section 3.3 below, the proposed deprecated features are identified, together with possible functional replacements. in Fortran Forum 3(2) June 1984 view details in Fortran Forum 3(2) June 1984 view details in Fortran Forum 6(3) December 1987 view details History After the committee finished the 77 Standard, a number of the members agreed to carry on to create the next standard. They recognized there was much to do: array operations, block structures (CASE, some form of REPEAT), and various types (POINTER, STRING, BIT, BYTE) and INCLUDE were some of the important features that were not in FORTRAN 77. The goal was to complete the next standard by 1982. The committee's initial plan was to develop a core Fortran concept. Modules could be added to this core, e.g., array operations might be such a module. The advantages of this approach are incrementally new standards and incrementally new compilers. This core idea evolved into providing a module program-unit and structure definition in the language as the principal means of configuring global entities and providing extensibility. The process of completing the 8x standard for public comment was eventful. In January '86, the current draft failed to pass an internal vote because the committee felt the language was too large. The solution was to delete features (principally: BIT data type, event/error handling and some array features) by moving them to Appendix F, Removed Extensions. Appendix F preserves the committee's work and suggests carefully thought-out approaches to implementors who wish to provide these capabilities. In the 77 Standard, Hollerith constants were described in such an appendix. The June 87 Standard we are reviewing received several no votes, including IBM, DEC and Boeing Computer Services, all for essentially different reasons. Both DEC and IBM voted no on the 77 Standard. Extract: Accomplishments Accomplishments FORTRAN 77 source programs are fully compatible with Fortran 8x. 8x defines array processing, recursion, structured programming constructs and derived types as well as many new intrinsic functions. An important approach of the 8x standard is the one that preserves compiled-code compatabilty with Fortran 77. Careful implementors can preserve FORTRAN 77 compiled libraries and program units; a programmer could continue to maintain old program units in the existing FORTRAN 77 and code new subprograms in 8x. This observation is made without a detailed study of input/output and other fine points. Also, installations that take advantage of this would have to maintain two runtime libraries. Extract: Errors - wrong in F77 should be fixed Wrong in 77 There were mistakes introduced in FORTRAN 77 which, if are not changed in 8x, may never be corrected. These mistakes and other 77 features which are no longer needed or are recognized as poor programming practices are identified in 8x Standard Appendix B, Decremental Features. Appendicies are not part of the standard, they are included for information purposes only. To maintain compatability with 77, the committee hasn't removed these features which have been in use for as long as programmers had a 77 implementation available. There is precedent for removing features without warning: FORTRAN 77 eliminated the extended range of the DO. The features are: - DO index can be REAL, - ENTRY statements in functions, and - GO TO a labeled END IF from outside the BLOCK IF construct. Strict adherence to the ASCII collating sequence has never been a part of the standard. If we have national standards for both character sets and languages, shouldn't it be sufficient to state that the character set is ASCII. Intrinsic routines are defined in 77, i.e., LGT, LGE ..... to handle ASCII comparisions in a portable way. These intrinsic functions are superfluous and should be deleted. 8x has two more: ACHAR and IACHAR. A standard processor should internally use the ASCII character set and the results should be invisible to the programmer. Although the INTRINSIC statement is not listed in Appendix B, Decremental Features, this seldom used feature should be eliminated. Users can write their own external function that does the same thing without the kludge that most, if not all, compilers use to provide this capability. Example: * 77&8x * Lahey's88 INTRINSIC SIN CALL SUB(SIN) END EXTERNAL SINEMINE CALL SUB(SINEMINE) END FUNCTION SINEMINE(X) SINEMINE = SIN(X) END Extract: Errors - Missing in F8x Missing The INCLUDE statement has not been standardized, partly because 8x defines a more general solution, MODULE and USE. I claim that every 8x implementation, since most 77's have it, will have the INCLUDE statement to preserve existing code. Isn't one of the purposes of standardization for the committee to look at existing implementations and standardize them? 8x needs more minimums of maximums for language implementation parameters. One that exists is the number of dimensions for an array is seven. Currently, a programmer has to survey all the systems a program is to run on and then program to the minimums he finds. Lack of these limits reduces portability and even results in poor implementations. The three minimums of maximums that I see missing are: - the length of CHARACTER entities; - the number of Internal procedures allowed In a program unit; - the number of derived types allowed in a program unit. 28 A feature that would increase portability is conditional compilation. Since its first standardization, Fortran has recognized the need to experiment with features by stating: "A standard-conforming processor may allow additional forms and relationships provided that such additions do not conflict with the standard forms and relationships." Another quote: "The purpose of this standard is to promote portability .... " Many application programmers need to have their programs run on more than one system. Conditional compilation would permit one source file to run on all 8x-conforming systems. Extract: Errors - In F8x but could be done better Different 8x introduces a free-form syntax for source files. The features are: - upper and lower case, compiler translates nonCHARACTER constants to upper case - multiple statements per line, delimiter is ';' - trailing comments on each line, delimiter is '!' - continued statements are indicated by '&' being the last character in the line that is not part of the trailing comment Example: 10 a=l; b=a; c=0 ! Initialization IF ( a .EQ. b ) & ! Loop THEN ! Main part I prefer '&' being the first nonblank character on the continued line since it is more "Fortranish," i.e., FORTRAN 77 continues statements by column 6 (the first nonblank character the reader sees) being a nonblank, nonzero character. In 8x, functions can return arrays or defined-type structures in addition to the single value currently available in FORTRAN 77. The following code defines a real function that returns an array of 500 values: * 8x * Lahey's 88 TYPE many REAL f REAL X(500) EXTERNAL f(500) END TYPE TYPE (many) f Declaring dimensions in EXTERNAL context denotes it is a function that returns an array value - hardly any new syntax and a move towards putting all external references in an EXTERNAL declaration. There are so many new INTRINSIC functions that hits on existing user-defined procedure names are likely. As recommended in 77, programmers can solve this problem by using the EXTERNAL declaration in all program units. An interface block defines subprogram interfaces and some 8x features require its use. Restrict interface blocks to MODULEs (or INCLUDE files) and reduce the likelihood of different declarations of the same interface block in different program units. Extract: Errors - In F8x but shouldn't be Shouldn't be In For a language that is already large, another syntax to declare attributes has been introduced and is therfore undesirable; e.g., REAL, SAVE, ARRAY(10,1O) :: X, Y Let's stick with the historical form of declarations, even if it is not ideal. Furthermore, if the committee introduces syntax that duplicates existing syntax and the Decremental Features Appendix exists, shouldn't the "old" form be in that appendix? Another introduced duplication of syntax that I object to is ">=" for .GE., "==" for .EQ., etc. Would 8x be approved if attributes and relational operators were the only changes to the 77 standard? 29 The CONTAINS statement delimits a procedure from its internal procedures - it is not needed. Fortran, unlike COBOL, has never delimited the transition from declaration to executable, why begin now? Move RANGE and IDENTIFY, part of array operations, to Appendix F, Removed Extensions, and return vector-valued subscripts. Two array processing companies that have implemented array processing use vector-valued subscripts. Further, FORTRAN 77 allows an array element to subscript an array so the extension seems natural. Example: * 77 * Lahey's88 10 INTEGER I(10), J(20) INTEGER I(10), j(20) DO 10 N=1,20,2 DO n=1,20,2 I(N)=N i(n)=n DO 20 N=1,10 END DO J(I(N))= j(i)=... Extract: Mr Lahey's Perspective Perspective I programmed the compiler of the first implementation of FORTRAN 77 on the Honeywell 6600 under the DTSS Operating System. Mr. Robert Wegsten was responsible for the runtime package. We passed acceptance tests during November '75, and we changed the language system as the Standard changed. Customers include General Motors, Union Carbide, Hughes Aircraft and Citibank. In February '82, Mr. Bruce Bush and I began to port the DTSS system to the PC and sold the first copy of F77L during September '84. Since then we have made two major releases, received favorable reviews including Editor's Choice of PC Magazine, and sold more than 5,000 copies. F77L is the leading implementor of 8x features: recursion, 31-character names with the underscore character, lower case letters, the quote character as a synonym for apostrophe in delimiting CHARACTER constants, and the IMPLICIT NONE and NAMELIST statements. in Fortran Forum 6(3) December 1987 view details in Fortran Forum 6(3) December 1987 view details External link: Online copy in Fortran Forum 8(4) December 1989 view details External link: Online copy in Fortran Forum 8(2) May 1989 view details in Fortran Forum 8(2) May 1989 view details 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 External link: Online copy Extract: Naming the baby Naming the baby. How does Fortran 90 roll off your tongue? As John Reid reports, "... the informal name 'Fortran 90' was unanimously adopted [at the X3J3 meeting in January 1990], an earnest of the intention to finish this year." WG5 had recommended "Fortran 88" a couple of years ago. Even earlier (19807), Stu Feldman said he assumed that the X in "Fortran 8X" represented a hexadecimal digit: so, should 90 be spelled '8A'? (??? But 90 in hex is 5A.) Extract: Double standards Double standards. In action completed by-X3 (the "parent" of Fortran technical committee X3J3 in the ANSI standards hierarchy) at its meeting in October 1989, two separate tracks were created for ANSI Fortran standards. Fortran 90 will not replace Fortran 77; but will coexist with it as a separate ANSI standard. It is the intent of X3 that Fortran 77 will never be revised, although it may continue indefinitely as a standard. X3 was apparently swayed by such precedents as Minimal-Basic / Basic, and Pascal / Extended-Pascal. (Algol-60 / Algol-68 ?) Although supported by a minority within X3J3, this action was not initiated nor promoted as a recommendation of the Fortran technical committee. In fact, the view of many X3J3 members was dismay that so significant a change in the charter of the technical committee was made without its participation (and presumably over its objection: both X3J3 and the ISO Fortran working group WG5 have resisted the notion of identifying a subset of Fortran 90; a proposal to accept Fortran 77 as the only standard subset had recently received lukewarm support, perhaps gaining a bit more favor as a desperate but belated alternative to the X3 action). So there will be two ANSI Fortran standards: Fortran 77 and Fortran 90. Meanwhile, ISO groups have voiced their clear intent that Fortran 90 will be the only international Fortran standard. The practical effect of the X3 action will probably be a slight delay in some early implementations of Fortran 90: there will be a bit less pressure to replace Fortran 77 right away, since it will remain as a standard language. But software implementors with a significant overseas Fortran market will have a stronger incentive to implement Fortran 90, and once the implementation exists they will have no reason to withhold it from the US market. Extract: Loss of non-roman character set Delete the "user-specified character set" for source programs. (This feature could have permitted a variable name with an umlaut-a or a tilde-n, with a Greek letter such as alpha, or with a Kanji character. The feature was added to the May 1989 draft in response to a perceived international requirement that now seems to have been overestimated.) in Fortran Forum 9(2) October 1990 view details External link: Online copy in Fortran Forum 9(2) October 1990 view details in Fortran Forum 9(2) October 1990 view details in Fortran Forum 9(2) October 1990 view details Resources
|