FORTRAN IV(ID:160/for060)

first major release of FORTRAN 

(also FORTRAN-62)

IBM 1962, this went well beyond the original definition.
Places Hardware:
Related languages
FORTRAN III => FORTRAN IV   Evolution of
MAD => FORTRAN IV   Incorporated some features of
FORTRAN IV => AKI   Influence
FORTRAN IV => ALGAN   Extension of
FORTRAN IV => AMPPL-I   Extension of
FORTRAN IV => AMPPL-II   Augmentation of
FORTRAN IV => ANALITIK   Influence
FORTRAN IV => APESE   Augmentation of
FORTRAN IV => Atlas Fortran V   Extension of
FORTRAN IV => B4Tran   Augmentation of
FORTRAN IV => BAL   Extension of
FORTRAN IV => Basic FORTRAN   Subset
FORTRAN IV => BRL FORTRAN   Implementation
FORTRAN IV => CATO   Influence
FORTRAN IV => CFD   Extension of
FORTRAN IV => COIF   Augmentation of
FORTRAN IV => CORAL   Influence
FORTRAN IV => CORC   Mild Influence
FORTRAN IV => CSSL   Incorporated some features of
FORTRAN IV => Day state transitions   Extension of
FORTRAN IV => DIBOL   Evolution of
FORTRAN IV => DIGRAF   Extension of
FORTRAN IV => DOCUS   Target language for
FORTRAN IV => DSL/90   Augmentation of
FORTRAN IV => DYSTAL   Extension of
FORTRAN IV => Early ALTRAN   Extension of
FORTRAN IV => EFL   Extension of
FORTRAN IV => ELMAMETA   Extension of
FORTRAN IV => ETC   Influence
FORTRAN IV => FGRAAL   Extension of
FORTRAN IV => FIDIL   Extension of
FORTRAN IV => Force III   Extension of
FORTRAN IV => FORDESK IV   Extension of
FORTRAN IV => FORGO   Simplification of
FORTRAN IV => FORMAT-FORTRAN   Extension of
FORTRAN IV => FORTAB   Written using
FORTRAN IV => FORTRAN 63   Augmentation of
FORTRAN IV => FORTRAN 66   Standardisation
FORTRAN IV => FORTRAN H   Augmentation of
FORTRAN IV => Fortran M   Extension of
FORTRAN IV => FORTRAN V   Extension of
FORTRAN IV => FORTRAN V   Extension of
FORTRAN IV => FORTRAN-RPG   Extension of
FORTRAN IV => GASP II   Written using
FORTRAN IV => Gentleman's Portable Coroutine System   Based on
FORTRAN IV => GENTRAN   Targetting
FORTRAN IV => GRAAL   Extension of
FORTRAN IV => GRAF   Augmentation of
FORTRAN IV => GRAFIC   Extension of
FORTRAN IV => HYTRAN   Partly Based on
FORTRAN IV => ICETRAN   Extension of
FORTRAN IV => IVTRAN   Extension of
FORTRAN IV => JFLIP   Extension of
FORTRAN IV => JOSTRAN   Output language
FORTRAN IV => LABTRAN   Extension of
FORTRAN IV => LFP   Preprocessor for
FORTRAN IV => LFP   Extension of
FORTRAN IV => LINUS   Influence
FORTRAN IV => LPG   Influence
FORTRAN IV => MADTRAN   Target language for
FORTRAN IV => MANIP   Extension of
FORTRAN IV => MORTRAN   Extension of
FORTRAN IV => NSFTRAN   Augmentation of
FORTRAN IV => Opus   Extension of
FORTRAN IV => Orion FORTRAN   Extension of
FORTRAN IV => PL/ACME   Written using
FORTRAN IV => PL/I   Influence
FORTRAN IV => PL-11   Written using
FORTRAN IV => POFAC   Extension of
FORTRAN IV => PROTRAN   Extension of
FORTRAN IV => PUFFT   Implementation
FORTRAN IV => QDGS   Extension of
FORTRAN IV => QUICKTRAN   Subset
FORTRAN IV => RALPH   Compiled by
FORTRAN IV => RATFOR   Extension of
FORTRAN IV => RATMAC   Extension of
FORTRAN IV => RC-Fortran   Augmentation of
FORTRAN IV => SAC-1   Written using
FORTRAN IV => SALOME   Extension of
FORTRAN IV => SFTRAN   Extension of
FORTRAN IV => SLIP   Augmentation of
FORTRAN IV => SP/1   Preprocessor for
FORTRAN IV => SPIFFY   Extension of
FORTRAN IV => STAR   Preprocessor for
FORTRAN IV => STREX   Extension of
FORTRAN IV => SYMBOLANG   Augmentation of
FORTRAN IV => TALL   Target language for
FORTRAN IV => TREETRAN   Augmentation of
FORTRAN IV => WATFOR   Subset

Samples:
References:
  • Sammet, Jean E "1960 Tower of Babel" diagram on the front of CACM January 1961 view details

          in [ACM] CACM 4(01) (Jan 1961) view details
  • Robbins, D. K., "FORTRAN for Business Data Processing" view details
          in [ACM] CACM 5(07) July 1962 view details
  • Allen, J. J., Moore, D. P., and Rogoway, H. P., "SHARE Internal FORTRAN Translator" view details
          in Datamation 9(3) March 1963 view details
  • Heising, W. P., "FORTRAN" view details
          in [ACM] CACM 6(03) (Mar 1963) view details
  • Pyle, I. C. "Dialects of FORTRAN" view details
          in [ACM] CACM 6(08) (August 1963) view details
  • "FORTRAN vs. Basic FORTRAN-A Programming Language for Information Processing on Automatic Data Processing Systems" view details
          in [ACM] CACM 7(10) October 1964 view details
  • [IBM] IBM Operating System1360: FORTRAN IV, IBM Corp., C28-6515-2, Data Processing Division, White Plains, N.Y. (1964). view details
          in [ACM] CACM 7(10) October 1964 view details
  • Backus, J. W., and Heising, W. P. (1964) August. "FORTRAN" view details
          in [ACM] CACM 7(10) October 1964 view details
  • Heising, W. P., "FORTRAN: Compatibility & Standardization" view details
          in Datamation 10(8) Aug 1964 view details
  • Heising, W. P., "History and Summary of FORTRAN Standardization Development for the ASA" view details
          in [ACM] CACM 7(10) October 1964 view details
  • Leavenworth, B review of Heising 1963 (FORTRAN IV) view details Abstract: This paper gives a history of FORTRAN documentation starting with "The FORTRAN Automatic Coding System for the IBM 704 EDPM" (dated October 15, 1956), and lists a few of the more popular manuals (704 FORTRAN II, 709 FORTRAN, etc.). Present documentation consists of a reference manual for each machine, and a general information manual which serves as a primer, and contains additional information relative to each machine type.

    A brief account is given of some interesting problems in the maintenance of a programming system. In particular, the author discusses the use of the system editing program, the handling of reported system errors, and the testing of modifications. As the FORTRAN systems of today reflect the experience and suggestions of the many users, the author advises that "compiler authors must make real efforts not to lapse into ivory towers, if their product is to make the transition from a toy to a workhorse." He also stresses the fact that users today want a programming system, not merely a compiler.

          in ACM Computing Reviews 5(01) January-February 1964 view details
  • Oswald, H., "The Various FORTRANS" view details
          in Datamation 10(8) Aug 1964 view details
  • Rosen, Saul "Programming Systems and Languages: a historical Survey" (reprinted in Rosen, Saul (ed) Programming Systems & Languages. McGraw Hill, New York, 1967) view details Extract: FORTRAN languages
    The 701 used a rather unreliable electrostatic tube storage system. When Magnetic core storage became available there was some talk about a 701M computer that would be an advanced 701 with core storage. The idea of a 701M was soon dropped in favor of a completely new computer, the 704. The 704 was going to incorporate into hardware many of the features for which programming systems had been developed in the past. Automatic floating point hardware and index registers would make interpretive systems like Speedcode unnecessary.
    Along with the development of the 704 hardware IBM set up a project headed by John Backus to develop a suitable compiler for the new computer. After the expenditure of about 25 man years of effort they produced the first Fortran compiler.19,20 Fortran is in many ways the most important and most impressive development in the early history of automatic programming.
    Like most of the early hardware and software systems, Fortran was late in delivery, and didn't really work when it was delivered. At first people thought it would never be done. Then when it was in field test, with many bugs, and with some of the most important parts unfinished, many thought it would never work. It gradually got to the point where a program in Fortran had a reasonable expectancy of compiling all the way through and maybe even of running. This gradual change of status from an experiment to a working system was true of most compilers. It is stressed here in the case of Fortran only because Fortran is now almost taken for granted, as if it were built into the computer hardware.
    In the early days of automatic programming, the most important criterion on which a compiler was judged was the efficiency of the object code. "You only compile once, you run the object program many times," was a statement often quoted to justify a compiler design philosophy that permitted the compiler to take as long as necessary, within reason, to produce good object code. The Fortran compiler on the 704 applied a number of difficult and ingenious techniques in an attempt to produce object coding that would be as good as that produced by a good programmer programming in machine code. For many types of programs the coding produced is very good. Of course there are some for which it is not so good. In order to make effective use of index registers a very complicated index register assignment algorithm was used that involved a complete analysis of the flow of the program and a simulation of the running of the program using information obtained from frequency statements and from the flow analysis. This was very time consuming, especially on the relatively small initial 704 configuration. Part of the index register optimization fell into disuse quite early but much of it was carried along into Fortran II and is still in use on the 704/9/90. In many programs it still contributes to the production of better code than can be achieved on the new Fortran IV compiler.
    Experience led to a gradual change of philosophy with respect to compilers. During debugging, compiling is done over and over again. One of the major reasons for using a problem oriented language is to make it easy to modify programs frequently on the basis of experience gained in running the programs. In many cases the total compile time used by a project is much greater than the total time spent running object codes. More recent compilers on many computers have emphasized compiling time rather than run time efficiency. Some may have gone too far in that direction.
    It was the development of Fortran II that made it possible to use Fortran for large problems without using excessive compiling time. Fortran II permitted a program to be broken down into subprograms which could be tested and debugged separately. With Fortran II in full operation, the use of Fortran spread very rapidly. Many 704 installations started to use nothing but Fortran. A revolution was taking place in the scientific computing field, but many of the spokesmen for the computer field were unaware of it. A number of major projects that were at crucial points in their development in 1957-1959 might have proceeded quite differently if there was more general awareness of the extent to which the use of Fortran had been accepted in many major 704 installations.

          in [AFIPS JCC 25] Proceedings of the 1964 Spring Joint Computer Conference SJCC 1964 view details
  • Fano, Robert "The MAC system: a progress report" pp131-150 view details
          in Sass, M. and W. Wilkinson, eds. Computer Augmentation of Human Reasoning Spartan Books, Washington, D.C., 1965 view details
  • McCracken, D. D., "How to Tell If It's FORTRAN IV" view details
          in Datamation 11(10) Oct 1965 view details
  • Samuel, A.L. "Time Sharing on a Multiconsole Computer" MIT-LCS-TR-017 1965 view details
          in Datamation 11(10) Oct 1965 view details
  • [IBM] IBM 709017094 IBSYS Operating System-Version 13: FORTRAN IV Language, IBM Corp., C28-6390-3, Data Processing Division, White Plains, N.Y. (Apr., 1966). view details
          in Datamation 11(10) Oct 1965 view details
  • USA Standard FORTRAN, United States of America Standards Institute, USAS X3.9-1966, New York, Mar., 1966. view details
          in Datamation 11(10) Oct 1965 view details
  • Albany, A. E. J. "FORDESK IV - The Design and Implementation of a FORTRAN IV Interpreter" view details Abstract: This paper discusses the design and implementation of a FORTRAN IV interpreter with regard to its on-line use in a time-shared system. An account is given of the development and operation of the current version of FORDESK IV. The features incorporated to enable on-line generation, debugging and editing of programs are described and some of the problems encountered with incremental compilation are discussed. Comparisons are drawn with BASIC and other on-line interpretive languages. Mention is also made of the design aims of re-entrant operation and batch processing of student problems. The reasons for the choice of FORTRAN as the language to be implemented and the advantages of compatibility with the standard FORTRAN IV compiler are discussed and offered as the major reasons for the successful acceptance of FORDESK. Extract: COMPARISONS WITH BASIC AND AID
    […]two interpretive conversational languages for the PDP-6 which fulfill the conversational on-line desk calculator aims of FORDESK. These are a version of advanced BASIC, the language developed by Dartmouth College and used by the G.E. time-sharing systems, and a language called AID which is based on the JOSS language developed by the RAND Corporation (J. C. Shaw, 1964).

    COMPARISONS WITH BASIC AND AID
    BASIC is designed for business and educational problem solving applications as well as for scientific work, while AID is designed chiefly for scientific and engineering problem solving By comparison FORDESK falls between the two, being better suited for most scientific work than BASIC and better suited for business type applications than AID. Also, as it is hoped eventually to implement all of FORTRAN IV, features such as double precision or complex arithmetic that exist in neither BASIC nor AID will become available in FORDESK.

    FORTRAN is a harder language to learn than either BASIC or AID as it is further removed from normal English syntax It is interesting to note though, that current FORDESK I users do not seem inclined to spend the time to learn either BASIC or AID, preferring to use FORDESK, with which they are familiar.

    In basic design all three languages are much the same, having arithmetic, jump, test and loop instructions but each has some features not found in the others. BASIC has a powerful set of matrix operations which allow matrices to be manipulated in a similar fashion to scalar variables and also some powerful character manipulation instructions AID has a set of functions PROD, SUM, MAX and MIN whose arguments can be specified in an iterative clause similar to mathematical notation but which a FORTRAN programmer would have to translate into a DO loop. AID and BASIC have a syntax better suited to conversational operation. The "up arrow" symbol for exponentiation in BASIC and AID is preferable to the " " used in FORTRAN while AID also has "' !" for absolute value and "[ ]" interchangeable with "( )" for greater legibility.

    These features cannot be incorporated into FORDESK as they are not compatible with FORTRAN IV.

    Variable names are restricted to one letter in AID and to one letter or one letter followed by a digit in BASIC, restrictions which limit the number of variables that can be used and prevent a user making his names mnemonic. FORDESK I users found the restriction to one letter variable names inconvenient because of these reasons. However, FORDESK IV follows the FORTRAN convention of variable names being up to six alphanumeric characters long with characters after the sixth ignored.

    FORDESK has a more extensive set of arithmetic functions than either BASIC or AID and it goes one step further in its debugging facilities by allowing breakpoints to be set in a program. The current version of FORDESK occupies 5K of core as does BASIC, but AID needs 11K of core, thus the use of AID results in increased overheads in the swapping system. FORDESK is designed to operate re-entrantly to further reduce its swapping overheads

    FORTRAN statements typed into FORDESK can start immediately after the line number so it is not necessary to space or tab across to represent card image. Rather, statement numbers are delimited by a colon or a tab and similarly comments are indicated by a "C" followed by a colon or tab. The line numbers provided by FORDESK are for reference in FORDESK commands only and are not used as FORTRAN statement numbers. Thus if resequencing of FORTRAN statements is requested, the actual program does not have to be modified. In addition, this will mean that it will be possible to input normal FORTRAN programs from sources other than the teletype.
    Having received a statement, FORDESK interprets it immediately and if possible executes it. If an arithmetic statement is executed at this stage, the result is typed out immediately as a guide to the correctness of the user's program. Execution is suspended if a jump instruction is typed which would transfer control to a currently undefined statement number. Execution resumes when the statement number is defined. If an error is detected then FORDESK types a diagnostic message and asks for the same line to be retyped.

    The user can return to command mode from text mode by pressing the ALTMODE key on the teletype instead of entering a FORTRAN statement.
          in Proceedings of the Fourth Australian Computer Conference Adelaide, South Australia, 1969 view details
  • Harrison, Malcolm C "Data-structures and programming" New York: Courant Institute of Mathematical Sciences 1970 view details
          in Proceedings of the Fourth Australian Computer Conference Adelaide, South Australia, 1969 view details
  • [System Development Corp. Santa Monica, California] ADEPT-50 M70-10229 view details
          in Computer Program Abstracts Cumulative Issue July 15, 1969 -- July 15, 1971 view details
  • Rosen, S. "Programming Systems and Languages 1965-1975" view details Abstract: In spite of impressive gains by PL/I, Fortran and Cobol remain the languages in which most of the world's production programs are written and will remain so into the foreseeable future. There is a great deal of theoretical interest in Algol 68 and in extensible languages, but so far at least they have had little practical impact. Problem-oriented languages may very well become the most important language development area in the next five to ten years. In the operating system area all major computer manufacturers set out to produce very ambitious multiprogramming systems, and they all ran into similar problems. A number of university projects, though not directly comparable to those of the manufacturers, have contributed greatly to a better understanding of operating system principles. Important trends include the increased interest in the development of system measurement and evaluation techniques, and increased use of microprogramming for some programming system functions. DOI
          in [ACM] CACM 15(07) (July 1972) view details
  • Sammet, Jean E., "Programming languages: history and future" view details
          in [ACM] CACM 15(06) (June 1972) view details
  • Meissner, Loren P. "A method to expose the hidden structure of Fortran programs" pp193-198 view details Extract: Extensions to FORTRAN IV
    Extensions to Standard Fortran. One possible way to gain some of the advantages of structured programming would be to add the keywords "if ... then ... else" and "do ... while" to Fortran.
    Several experiments have been made in this direction, including "structured Fortran" extensions named DEFT, IFTRAN, LINUS, MORTRAN, SFTran, and SPIFFY. (No doubt there are others.)
          in Proceedings of the 1974 ACM Annual Conference San Diego, November, 1974 view details
  • Hager, Oberita "An Evaluation of the Data Processing Program at Eastern Kentucky University" view details
          in Proceedings of the 1974 ACM Annual Conference San Diego, November, 1974 view details
  • Jacobsen, Henrik "RC4000, RC8000 and RC9000" (accessed on 030117) view details External link: Online article
          in Proceedings of the 1974 ACM Annual Conference San Diego, November, 1974 view details
  • Galler and Galler "A Career Interview with Bernie Galler" pp22-33 view details Extract: MAD
    I should talk a little about the history of MAD, because MAD was one of our major activities at the Computing Center. It goes back to the 650, when we had the IT compiler from Al Perlis. Because of the hardware constraints - mainly the size of storage and the fact that there were no index registers on the machine - IT had to have some severe limitations on what could be expressed in the language. Arden and Graham decided to take advantage of index registers when we finally got them on the 650 hardware. We also began to understand compilers a little better, and they decided to generalize the language a little. In 1957, they wrote a compiler called GAT, the Generalized Algebraic Translator. Perlis took GAT and added some things, and called it GATE - GAT Extended.
    GAT was not used very long at Michigan. It was okay, but there was another development in 1958. The ACM [Association for Computing Machinery] and a European group cooperatively announced a "standard" language called IAL, the International Algebraic Language, later changed to Algol, Algorithmic Language, specifically Algol 58. They published a description of the language, and noted: "Please everyone, implement this. Let's find out what's wrong with it. In two years we'll meet again and make corrections to the language," in the hope that everyone would use this one wonderful language universally instead of the several hundred already developing all over the world. The cover of an issue of the ACM Communications back then showed a Tower of Babel with all the different languages on it.
    John Carr was very active in this international process. When he returned to Michigan from the 1958 meeting with the Europeans, he said:
         We've got to do an Algol 58 compiler. To help the
         process, let's find out what's wrong with the language.
         We know how to write language compilers,
         we've already worked with IT, and we've
         done GAT. Let's see if we can help.
    So we decided to do an Algol 58 compiler. I worked with Arden and Graham; Carr was involved a little but left Michigan in 1959. There were some things wrong - foolish inclusions, some things very difficult to do -  with the Algol 58 language specification. When you write a compiler, you have to make a number of decisions. By the time we designed the language that we thought would be worth doing and for which we could do a compiler, we couldn't call it Algol any more; it really was different. That's when we adopted the name MAD, for the Michigan Algorithm Decoder. We had some funny interaction with the Mad Magazine people, when we asked for permission to use the name MAD. In a very funny letter, they told us that they would take us to court and everything else, but ended the threat with a P.S. at the bottom - "Sure, go ahead." Unfortunately, that letter is lost.
    So in 1959, we decided to write a compiler, and at first it was Arden and Graham who did this. I helped, and watched, but it was mainly their work because they'd worked on GAT together. At some point I told them I wanted to get more directly involved. Arden was doing the back end of the compiler; Graham was doing the front end. We needed someone to do the middle part that would make everything flow, and provide all the tables and so on. I said, "Fine. That's my part." So Graham did part 1, Galler did part 2, and Arden did part 3.
    A few years later when Bob Graham left to go to the University of Massachusetts, I took over part 1. So I had parts 1 and 2, and Arden had 3, and we kept on that way for several years. We did the MAD compiler in 1959 and 1960, and I think it was 1960 when we went to that famous Share meeting and announced that we had a compiler that was in many ways better and faster than Fortran. People still tell me they remember my standing up at that meeting and saying at one of the Fortran discussions, "This is all unnecessary, what you're arguing about here. Come to our session where we talk about MAD, and you'll see why."
    Q: Did they think that you were being very brash, because you were so young?
    A: Of course. Who would challenge IBM? I remember one time, a little bit later, we had a visit from a man from IBM. He told us that they were very excited at IBM because they had discovered how to have the computer do some useful work during the 20-second rewind of the tape in the middle of the Fortran translation process on the IBM 704, and we smiled. He said, "Why are you smiling?" And we said, "That's sort of funny, because the whole MAD translation takes one second." And here he was trying to find something useful for the computer to do during the 20-second rewind in the middle of their whole Fortran processor.
    In developing MAD, we were able to get the source listings for Fortran on the 704. Bob Graham studied those listings to see how they used the computer. The 704 computer, at that time, had 4,000 36-bit words of core storage and 8,000 words of drum storage. The way the IBM people overcame the small 4,000-word core storage was to store their tables on the drum. They did a lot of table look up on the drum, recognizing one word for each revolution of the drum. If that wasn't the word they wanted, then they'd wait until it came around, and they'd look at the next word.
    Graham recognized this and said, "That's one of the main reasons they're slow, because there's a lot of table look-up stuff in any compiler. You look up the symbols, you look up the addresses, you look up the types of variables, and so on."
    So we said, fine. The way to organize a compiler then is to use the drum, but to use it the way drums ought to be used. That is, we put data out there for temporary storage and bring it back only once, when we need it. So we developed all of our tables in core. When they overflowed, we stored them out on the drum. That is, part 1 did all of that. Part 2 brought the tables in, reworked and combined them, and put them back on the drum, and part 3 would call in each table when it needed it. We did no lookup on the drum, and we were able to do the entire translation in under a second.
    It was because of that that MIT used MAD when they developed CTSS, the Compatible Time-Sharing System, and needed a fast compiler for student use. It was their in-core translator for many years.
    MAD was successfully completed in 1961. Our campus used MAD until the middle of 1965, when we replaced the 7090 computer with the System /360. During the last four years of MAD's use, we found no additional bugs; it was a very good compiler. One important thing about MAD was that we had a number of language innovations, and notational innovations, some of which were picked up by the Fortran group to put into Fortran IV and its successors later on. They never really advertised the fact that they got ideas, and some important notation, from MAD, but they told me that privately.
    We published a number of papers about MAD and its innovations. One important thing we had was a language definition facility. People now refer to it as an extensible language facility. It was useful and important, and it worked from 1961 on, but somehow we didn't appreciate how important it was, so we didn't really publish anything about it until about 1969. There's a lot of work in extensible languages now, and unfortunately, not a lot of people credit the work we did, partly because we delayed publishing for so long. While people knew about it and built on it, there was no paper they could cite.
          in IEEE Annals of the History of Computing, 23(1) January 2001 view details
  • Library of Congress Subject Headings F25 view details
          in IEEE Annals of the History of Computing, 23(1) January 2001 view details