Talk:Fortran

fortran 2003 is not object oriented!!!!

As far as I understood the basic definition of an object oriented language includes stuff like classes and inheritance. Fortran 2003 can emulate this, by using function pointers, but it is not part of the language. Therefore it is wrong to write that fortran is object oriented.—The preceding unsigned comment was added by 203.200.55.101 (talk • contribs) 07:57, 18 August 2006.

Even the article you link to says Fortran2003 is OO. Rangek 16:37, 18 August 2006 (UTC)

I replaced the brief 2003 text with Reid's summary.

Although it is correct to say "Fortran 2003 doesn't spell object-oriented programming concepts the same way that C++ does," it is incorrect to say "Fortran 2003 is not object oriented." The object-oriented programming model is consciously based upon Simula, not C++. Fortran 2003 has extensible types, inheritance, polymorphic variables, and type-bound procedures (in addition to procedure pointers); what else is needed to qualify it as "object oriented?" Van.snyder 20:03 22 August 2006 (UTC)

Objects? —Preceding unsigned comment added by 129.138.36.82 (talk) 19:05, 13 November 2008 (UTC)

I think that you will find inheritance & type-bound procedures defines what Fortran objects can do. —Preceding unsigned comment added by Bendel boy (talk • contribs) 08:43, 27 August 2009 (UTC)

For the record, C++ too based its model on Simula. Stroustrup states over and over again (in "The design and evolution of C++") that he liked the Simula model (and rejected the Smalltalk model, his other major reference point it seems). JöG (talk) 20:40, 18 December 2010 (UTC)

cleaning up the article

I took out all of the tutorials, books, etc. listed in the history section and put them in the external links section to make the page more readable. In addition I think it might be a good idea to add a separate page for the history of fortran for the details and make what's on the page more succinct. 130.215.112.54 22:41, 25 August 2006 (UTC) John S.

Sorry about that. I'll try to delete as many of my edits as I can, reverting as best as possible to the succinct, encyclopedic, July 18th version. btw, for anyone that wanted the fluff I addded (and am now deleting), you can always go to this history item

         22:04, 25 August 2006 130.215.112.54 (Talk) (removed unused "References" section)

and click "last". That should display the intact file, before John S.'s edit. Further, you can then click "edit", select all text, and save it to your own file. Can that file then be opened as a Wiki? I don't know, but you can always paste it into a sandbox to view as a Wiki. Apologies again for getting so far off-track.

re: Ryulong (Talk | contribs) m (JS: ..... Please do not compromise the integrity of pages.)

Well, a newby still learning: I had deleted the article text those discussions were in reference to, so it seemed (to me) reasonable to delete the discussions as well. What value is a discussion history of non-existant text? More apologies & thanks. btw "Any good-faith effort to improve the encyclopedia, even if misguided or ill-considered, is not vandalism."

Fortran Commands (for 66, 77, 90, 95, 2003...)

I wonder if you agree with me that Fortran commands should be written here. It could be useful to be able to compare it with another language's possibilities. (Or maybe they are already somewhere on Wikipedia???) Max

Blanks insignificant --before-- Fortran 90???

The section on "arcane syntax" states that blanks were not significant before Fortran 90. Surely that is the wrong way around? --Slashme 14:28, 8 September 2006 (UTC)

Yes, blanks were not significant before Fortran-90 (and, it still aren't in fixed-form). That means that the following was a valid program (all blanks are stripped before parsing):

     PROGRAMMING
     REALITY
     COMP LEX SPECIALIS
       I TY=2
     DOING=1,INT(I T Y)
         WR ITE(*,*) ING
     E N D D O
     END

output:

  1
  2

Duja 15:20, 8 September 2006 (UTC)

I think there is a little confusion on this matter. Early Fortran (like Cobol) was designed with storage on punched cards in mind, so certain fields on the card had significance:

• column 1 was the comment field: a C here caused the entire card to be ignored by the compiler
• columns 2 to 5 were the label field: a sequence of digits here was taken as a label for the purpose of a GOTO or a FORMAT reference in a WRITE or READ statement;
• column 6 was a continuation field: a non-blank character here caused the card to be taken as a continuation of the statement on the previous card.
• columns 73 to 80 were ignored; punched card machines sometimes placed a card sequence number here to guard loss of data by removal of cards or scrambling of order of cards in the deck.
• this left columns 7 to 72 as the statement field.

Within the statement field, blanks were insignificant, with the exception of so-called Hollerith designators, which normally appeared in FORMAT statements and were normally used to represent quoted text. Blanks and leading zeroes, I think, were also insignificant in the label field. --Tony Sidaway 14:00, 19 January 2007 (UTC)

Minor corrections/notes re the above:

In FORTRAN 77, column 1 could also contain an asterisk ("*") to indicate a comment.

X3J3 added the "*" as a result of Public Comment #1 on the dpANS for the revison of X3.9-1966

Columns 1 thru 5 were the label field (as long as column 1 did not contain a "C" or "*").

Any statement could have a "label" (or statement number) on its initial line.

The DO loop also required a number on its last statement (until Fortran 90).

In column 6, a zero ("0") would also indicate a new statement (as did a blank).

However, column 6 was ignored if column 1 made the statement a comment.

Columns 73-80 typically contained a "deck" identifiers and sequence numbers (often 4 columns each).

These were often punched automatically, using a wired board in the card "Reproducer" machine.

Incidentally, the reason for 72 columns was that IBM 70x computers read cards in "row binary", which meant that the 80 bits of each row were read into three consecutive 36-bit words per row. Backus discarded the last eight columns, skipping every third word for the sake of increased efficiency (which was his principal goal in developing the original FORTRAN).

One of the first tasks of the compiler was to gather together the twelve Hollerith bits from one column (stored at the same bit position in in twelve different words!) to produce each 6-bit BCD character, packed six per word. The use of columns 1-6 for non-statement information (comment, label, continuation) was also motivated by the 36-bit (6-character) word length, since these fields were all contained in a single word, with each line of a statement (from columns 7-72) contained in eleven 36-bit words. With a maximum of nine continuations beyond the initial line, 60 characters (in 110 words) was the maximum statement length -- before discarding blanks. FORTRAN 77 increased the number of continuation lines to nineteen, doubling the maximum statement length to 1320 (in the "Full Language"; the "Subset" remained at 660).

Tripodics 12:44, 30 August 2007 (UTC)

The IBM 704, 709, 7090, etc. computers did read "row binary", but only read 72 columns of a card, NOT 80. These 72 columns were read into consecutive pairs of words, NOT into 3 words. The card reader dropped the 8 columns, which could be selected by a control panel on the reader, NOT by software on the computer. However this only applied to the online card reader. If offline card equipment was used to transfer the deck to magnetic tape, all 80 columns could be read by the computer from the tape images. -- RTC (talk) 23:14, 21 November 2007 (UTC)

Minor additions to the above discussion regarding blanks:

While FORTRAN 66 generally ignored blanks within columns 7-72 (except within Hollerith fields, etc.), and concatenated initial and continuation lines into one long statement, there was at least one restriction on continuation: the initial line of a continued statement (after discarding blanks) could not be "END".

FORTRAN 77 added a further restriction that columns 1 thru 5 must be blank in a continuation line (i.e. where column 6 does not contain blank or zero and column 1 does not contain "C" or "*"). While this made life a bit easier for implementors (and grammarians), it actually invalidated some standard-conforming programs.

Tripodics (talk) 17:32, 18 February 2008 (UTC)

Too much emphasis on history

The section on the history of FORTRAN should be moved to the end of the article or to a separate page. A random reader will probably want to know about the features that fortran has now before he delves into the differences between FORTRAN 66 and FORTRAN 77.

Beg to differ. FORTRAN is an historical artifact and should not be revived or learned by newbies. —Preceding unsigned comment added by 202.82.33.202 (talk) 11:11, 7 September 2007 (UTC)

Textbooks

The textbook section as of 13 Dec 2006 is as follows.

• Chapman, Stephen J. (2003). Fortran 90/95 for Scientists and Engineers, 2nd ed., McGraw-Hill. ISBN 0-07-282575-8.
• Ellis, T. M. R., Ivor R. Phillips, Thomas M. Lahey (1994). Fortran 90 Programming, 1st ed., Addison Wesley. ISBN 0-201-54446-6.
• McCracken, Daniel D. (1961). A Guide to Fortran Programming. Wiley.
• McCracken, Daniel D. (1965). A Guide to Fortran IV Programming. Wiley.
• Metcalf, Michael, John Reid, Malcolm Cohen (2004). Fortran 95/2003 Explained. Oxford University Press.
• Nyhoff, Larry, Sanford Leestma (1995). FORTRAN 77 for Engineers and Scientists with an Introduction to Fortran 90, 4th ed., Prentice Hall. ISBN 0-13-363003-X.

This is an odd mixture of ancient FORTRAN, Fortran 90, and Fortran 2003 textbooks. I think the 1960s textbooks should be removed, since they would not be useful for someone learning Fortran today.

I also did a double-take when, reading the article a few minutes ago, I saw my old Fortran textbook from University (McCracken's Fortran IV) listed there. However these are references to the development of the language, and that's the subject of this article. The article isn't really intended solely to teach programmers how to program in Fortran. I think McCracken's books are excellent examples of textbooks on Fortran during its most popular period, before it was eclipsed by Pascal and C. The Fortran IV book was still in use well into the 1970s. --Tony Sidaway 08:51, 1 February 2007 (UTC)

Criticisms and rebuttals

I have removed the section named "Criticisms and rebuttals." In its present form it amounts to the exchange of advocacy and counter-advocacy, without any attribution of the opinions expressed.

If there is or was a public debate concerning the usability of Fortran, it should be possible to describe that debate, with references to significant expressions of opinion by the principal actors in that debate --Tony Sidaway 13:44, 19 January 2007 (UTC)

I feel deleting the entire section was not appropropriate. Some of the information was factual. How does one atrribute all opinions in a large article? statsone 03:44, 21 January 2007 (UTC)

I've no strong objection to its restoration, though I think it's unsuitable in its current form because it turns this article into an advocacy piece. One way in which Wikipedia's Neutral Point of View policy is formulated is: "assert facts, including facts about opinions — but do not assert opinions themselves." In its current form, the piece I removed expresses some opinions as facts. It is the case that we must always attribute opinions in Wikipedia. There are no exceptions. If you can't find a significant record of an opinion being expressed, then the opinion cannot be significant enough for the article. --Tony Sidaway 14:16, 22 January 2007 (UTC)

Split History of fortran into a separate article

I think that the section history of fortran should be put in a separate article or at least moved to the end of the fortran article. We should focus on writing a fortran-article that is helpful for a person that has just started learning about the language. This person will be interested in a short summary of the language features and a few descriptive programs. —The preceding unsigned comment was added by 90.184.26.120 (talk) 15:53, 22 March 2007 (UTC).

Fortran 90

I'm surprised there is no discussion of the FORTRADA '90 controversy.

If memory serves me every major FORTRAN vendor save one voted NO on the Fortran 90 standard. They were out voted by the fact that IBM gets one vote and every government lab that send a representative gets one vote.

The vendors hoped that F90 would standardize enhancements, suchs as records, and include statements. Instead, it turned out to be effectively a new language.

In many ways, F90 was the nail in FORTRAN's coffin. —The preceding unsigned comment was added by 12.44.243.251 (talk) 21:34, 8 May 2007 (UTC).

I think you're in a small minority as far as your opinion of the efficacy of the F90 standard. It's highly unlikely that I would be using Fortran today if the F90 features (or similar analogs) had not been added to the language. I also think you mischaracterize the controversy over the 1990 standard, wherein (according to a report I've seen [1]) a few holdouts managed to stack ANSI's X3J3 (and subsequently X3 itself) but were overridden by ISO's WG5. --Mr Wednesday 20:25, 30 August 2007 (UTC)

No, this is not correct. Many vendors voted yes on the Fortran 90 standard, as did nearly all of the "user" representatives on X3J3. (My recollection is that a majority of vendors were in favor, but I may be mistaken about that. I'll try to check this in my old minutes.) On the other hand, for various reasons, many vendors did stall the process (which was originally targeted for the mid-1980s).
Tripodics 23:11, 30 August 2007 (UTC)
Bruce A. Martin,
(X3J3 member from 1976 thru about 1995)

Object deck vs. absolute deck

When the IBM 1401 and 1440 produced (punched) the object deck, I recall an option to produce an "absolute" deck. I believe it was less cards than the object deck, and it ran the program faster. A short paragraph in the main aritcle would be good to explain some on these two decks. I do not have any refs to adequately write this. Can someone help. Thank you. LanceBarber 17:51, 30 August 2007 (UTC)

Coding conventions

Are there any widely used coding conventions? For example, Java has these.

dfrankow (talk) 20:40, 24 January 2008 (UTC)

I don't think any were formally established until long after Fortran was in widespread use. I wouldn't be surprised if that created interest in establishing coding standards or conventions. However, most fortran code I've worked on tends to look like one or the other of of two forms: structured and spaghetti. —EncMstr 21:00, 24 January 2008 (UTC)

FORTRAN V

It may be worth including mention of FORTRAN V which, as you all know, was a name adopted by some/several compiler providers for their own extended version of FORTRAN IV. Melcombe (talk) 16:40, 18 February 2008 (UTC)

I disagree that "FORTRAN V" should be singled out for mention.

Because IBM's successor to FORTRAN II was named FORTRAN IV (there was no release of III), and because that release served as the basis for the standardization effort (for what became "FORTRAN 66"), various other vendors tried to gain a marketing edge by adding some nonstandard calling their products something like "FORTRAN V" or "FORTRAN VI" (Control Data) or "FORTRAN 76" (GE). I don't think these variants are particularly significant (except that some of them introduced extensions that eventually made it into 77 or 90), but I'd have no objection to a list that includes a good sampling of them (but not merely "FORTRAN V"). Tripodics (talk) 17:41, 18 February 2008 (UTC)

Published validation report on ISO/IEC 1539 ???

Although Fortran 2008 is on the way, I still need to know if there is any validation to have been done on the any part of Fortran 2003 - ISO/IEC 1539. If there is no report published in literature, then the series of the standard are not valid, hence should not be implemented —Preceding unsigned comment added by 64.62.138.94 (talk) 05:32, 24 February 2008 (UTC)

IBM-1130 FORTRAN-IV vs. FORTRAN-EMU?

About 1978 I used an IBM-1130 computer to write several FORTRAN programs. I remember that IBM's FORTRAN compiler lacks some features of FORTRAN-IV specification, but that Eastern Michigan University had improved IBM product in a compiler called FORTRAN-EMU. For this reason I never used IBM FORTRAN, just FORTRAN-EMU. I think that the missed features was LOGICAL values: relational operators and logical IF, but I am not sure. Anybody knows anything about this matter? Aacini (talk) 03:45, 9 May 2008 (UTC)

At the end of the Fortran 66 standard, there is the definition of Basic Fortran. That is, a simplified subset. Some of the smaller computers used that subset. I believe that LOGICAL and such are some of the features not included. There is also 5 letter variable names instead of 6.

I have the IBM 1130 version of IBM's ECAP, which uses that subset. All the six letter variable names were converted to 5 by removing the two in the middle, and replacing them with Z. Gah4 (talk) 04:56, 17 July 2023 (UTC)

Humor, trivia or so...

I'm really missing something in the folklore/humor department. As is noted, FORTRAN have accumulated a lot of folklore over the years, yet almost nothing of it is mentioned.

Perhaps the most classical one is: "GOD is REAL, unless declared INTEGER". Now, this also perhaps goes into a trivia section, since this refers to the implicit typing of variables in FORTRAN (atleast up to F77). All variables starting on I to N (I think it was) were INTEGERs unless declared otherwise. All other variables were REAL, unless declared otherwise. I think the joke, as well as the typing system as such, should be significant enough to be mentioned on this page. Or is this perhaps too much for religious sensitive people? /bqt@softjar.se --212.112.174.86 (talk) 13:39, 21 November 2008 (UTC)

This has arisen several times in the past and there seems to be consensus to NOT fill up this article with all the trivia that has come up over the years. Note that there is a link in the article to wikiquote where the one you mention and many more are listed. Trivia sections on wikipedia are discouraged anyway. I am inclined to think that the section headed "Letter O considered harmful" should also be deleted as being trivial information. --Bduke (Discussion) 21:48, 21 November 2008 (UTC)

I recently helped someone debug some Visual Basic .NET code that was malfunctioning "with no apparent reason." Turns out there was a DEFINT I-N statement, something that effectively implements the Fortran rule, causing some variables to become integer without explicit declaration. No doubt the code was converted from a fortran source, and knowing this old rule certainly helped the analysis.WHPratt (talk) 16:57, 11 March 2009 (UTC)

Regarding the "Letter O considered harmful" incident, one significant difference is that this proposal was actually a part of the process leading to standardization of FORTRAN 77 (as were the various proposals for minimum trip-count), whereas the other mentioned items (e.g. "JESUS is not REAL") were merely observations based on the published standard. bam (talk) 04:33, 23 November 2008 (UTC)

GA Review

This review is transcluded from Talk:Fortran/GA1. The edit link for this section can be used to add comments to the review.

This article does not meet the good article criteria and has therefore failed its nomination. Issues include:

• References must be formatted per WP:CITE/ES to include at least publisher and access dates
• A lot of sections don't have any references
• Have a look at WP:LAYOUT; References goes after Notes
• Clean up External links per the template notice

Once these issues have been resolved, please feel free to renominate the article. Thanks! Gary King (talk) 17:05, 3 December 2008 (UTC)

Mismatched parentheses

In the Fortran 90 section, there is the example

 X(1:N)=R(1:N)*COS(A(1:N)))

There is one unmatched right parenthesis at the end of this. This can't be correct syntax, can it? I don't know this FORTRAN 90 syntax (they taught me basic FORTRAN 77 in college), so I can't fix this, nor even absolutely confirm it's incorrect. But few languages use parentheses both in matched pairs and separately, and my experience with FORTRAN 77 doesn't make me seriously suspect that it's the exception.

Will someone who knows this FORTRAN 90 syntax please address this?

71.242.6.231 (talk) 19:32, 3 October 2009 (UTC)

Fixed. Crumley (talk) 14:26, 6 October 2009 (UTC)

new keywords limit backward compatibility

Many of my old programs used variable names that became keywords in more modern Fortrans. It's not a complaint, just a fact to remember so Fortran's outstanding backward compatibility not be over sold. —Preceding unsigned comment added by Jclaer (talk • contribs) 02:47, 21 November 2009 (UTC)

True. I recently helped to convert a program that had been running for decades on an old computer. It used a subprogram named simply "SUBROUTINE READ ([with some arguments])". When compiled in Linux GFortran 90, strange errors were reported. It turns out that all of the program's READ statements were now accessing this subroutine instead of the built-in READ logic. Presumably, some new feature of this Fortran implementation permits one to call a subroutine as if it were a function, with no need for a "CALL" verb. Renaming the subroutine (E.g., READDATA or READX or XREAD or ...)fixed everything. WHPratt (talk) 18:00, 16 November 2010 (UTC)

This sounds like a bug in a particular compiler - not a feature of the language. Yes, standard Fortran (of any vintage) does allow you to have a subroutine named READ. There are no reserved words in the language; this is a deliberate design and a fair amount of work went into making sure that the language was unambiguous even when names such as READ were used. I would think it inappropriate to use this Wikipedia article as a place to list every compiler bug that someone has run into, even if they mistakenly attribute it as a language feature. This bug actually sounds familiar to me. I recall one compiler (on an HP Unix, I think) that failed to mangle Fortran procedure names, with the result that naming a subroutine READ caused a conflict with the C read() function. If that's the case mentioned here, it is not only a compiler bug, but a misdiagnosed one, as the conflict was not with the Fortran READ statement.172.248.237.4 (talk) 01:50, 16 June 2017 (UTC)Richard Maine

Yes, there should be no problem with subroutine names like that. In some cases, though, new functions have been added, and will be used in place of user-supplied functions (or subroutines) of the same name. The name needs to be in an EXTERNAL statement in routines where it is referenced. The standard doesn't reply this, as long as the name isn't the name of a Fortran function or subroutine, and most people don't put them in. On most systems, there are ways to distinguish names, avoiding conflicts with system library routines. Gah4 (talk) 06:33, 9 July 2021 (UTC)

FREQUENCY

I'm amazed to read that the first FORTRAN from 1957 included a FREQUENCY statement to signal the compiler to optimize coding of particular parts of the program. I don't recall seeing such statements in a few other languages of which I have some scanty knowledge. Why did it this fall out of favor - is it hard to implement, or just doesn't help much? Wnt (talk) 19:42, 22 December 2009 (UTC)

The first Fortran compiler was certain to have the code it produced compared to that produced by practised assembler programmers, so a great deal of effort went into its analysis. Notably, it performed a Monte-Carlo simulation of the paths through the program blocks with a view to choosing the best op-codes for the more frequent paths, and rather than have the compiler use standard guesses for the likelihood of the various results of say an IF-test, the FREQUENCY statement allowed the programmer to specify the relative frequencies anticipated. Similarly, a great deal of thought went into the schemes for addressing data, especially calculating locations from array index expressions and identifying common components, as in array A(i,j) and B(i,j) both having the same dimensions, so the offset for element (i,j) would be the same for both. The authors remarked that the resulting code often would surprise them, and would have been avoided by a human code producer because of the risk of a mistake being made in the intricate considerations, that would require a painful re-analysis should almost any aspect of the source code be changed. Subsequently, as the advantages over machine code became more apparent, and the number of people who just wanted results sooner without the tedium of learning assembler grew combined with ever-larger programmes, the extreme effort made by the first compiler writers (who were very highly-skilled!) became less important than producing a workable compiler for a new model of computer. Similarly, taking the time to produce high-quality code for a routine that would likely have a short running time and most often be run only once before being modified afresh, would be a waste of effort. And at the same time, skills in writing assembler source were thinning, precisely because of the success of higher-level languages, though fanatic coders live on.NickyMcLean (talk) 11:33, 16 June 2017 (UTC)

Does fortran support Thread-Local Storage(TLS)?

Does fortran support Thread-Local Storage(TLS)? —Preceding unsigned comment added by Liuzhiqiangcn (talk • contribs) 13:54, 10 March 2010 (UTC)

Yes, since the introduction of Coarray Fortran in Fortran 2008. Every image (Fortran’s counterpart to a thread) can maintain its own local variables and storage, as opposed to declaring coarrays (either by using the CODIMENSION attribute, or by using the [] syntax with the variable name, in the type declaration statement) to make them accessible to other images.  —PowerPCG5 (talk) 01:05, 12 March 2021 (UTC)

Fortran name mangling

Should we add some information about the name mangling issue in fortran, or add a link? A typical aspect of fortran is that there's no standard on the name mangling scheme. See [2] for details. Depending on your compiler you'll functions will be transformed into one of 36 possibilities, (0/1/2 underscores before, 0/1/2 underscores after, lowercase/uppercase names, string lengths after arguments or at the end). The gnu autotools provide m4 macros to deal with these issues. SiggyF (talk) 15:22, 8 July 2010 (UTC)

Technically, this is not a problem with Fortran. It only occurs when mixing Fortran with other languages, or otherwise going behind the scenes. Gah4 (talk) 05:02, 17 July 2023 (UTC)

...at least on some platforms. Is the same "function name to external symbol name" algorithm used on 1) all UN\*Xes, 2) on Windows, 3) on other platforms (including platforms on which Fortran was available before C was)? If not, it's even less relevant here, so, no, we shouldn't add some information about name mangling here.

(And the "external" link in the initial comment is just Name mangling § Name mangling in Fortran, not a true external link.) Guy Harris (talk) 06:18, 17 July 2023 (UTC)

Historical inaccuracy

It is not particularly important, but the satement 'After the release of the FORTRAN 66 standard, compiler vendors introduced a number of extensions to "Standard Fortran"' is a bit misleading; many extensions to Fortran II which didn't get included in Fortran IV had been introduced by various compiler vendors well before the release of Fortran 66, and none of these made it into Fortran 66. Some of us who had some experience of Fortran programming were horrified when first exposed to Fortran IV or Fortran 66 because it was a big step backwards in terms of technical capabilities. Michealt (talk) 21:22, 23 December 2010 (UTC)

WATFOR

I think there should be a mention of WATFOR, since a generation of us learned Fortran on that system. The article was oddly titled WATFIV (programming language). At least the original WATFOR was not meant to be a new "language" but an integrated compile-load-execute system for Fortran IV. I just moved it to drop the modifier; there is only one. Of course few were 100% compatible, but I would not call it a "variant". So I would add it to the Forran IV section, unles anyone has a better idea. W Nowicki (talk) 00:13, 6 April 2011 (UTC)

WATFIV has many features that are not in Fortran IV. It seems to me that it was used to test out Fortran 77 features before the release of the standard. And WATFIV removes one feature from Fortran IV and Fortran 66: non FORMAT statements can't start with FORMAT(. Specifically, you can't assign to members of an array named FORMAT. Gah4 (talk) 06:46, 9 July 2021 (UTC)

indentation of PROGRAM statement

In the example code, the PROGRAM and END PROGRAM statements were not indented. I've changed the example to indent them but now it occurs to me that newfangled Fortrans may not require such indentaton, and whether to indent them or not, especally when all other statements are indented, may be more a matter of style than syntax. Brad Hughes (talk) 22:39, 14 April 2011 (UTC)

Fortran vs. FORTRAN

Note 1 appears to be incorrect when it asserts that FORTRAN was always used prior to 1990 and Fortran from that point on. If you look at the picture of one of the original manuals, it clearly shows that Fortran was used in 1956. — Preceding unsigned comment added by Waynesewell (talk • contribs) 13:46, 23 June 2011 (UTC)

I agree. All instances of "FORTRAN" in the article should be change to "Fortran" per WP:ALLCAPS. It only makes the article harder to read and would be against Wikipedia policy even if it were always in all-caps. We don't copy stupid capitalization. Yworo (talk) 15:09, 25 August 2011 (UTC)

Recursion

As the subroutine support started with FORTRAN II, what is the purpose of putting Recursion section under FORTRAN I section. I suggest to move it under FORTRAN II section. --Vssun (talk) 02:30, 8 September 2012 (UTC)

Did early FORTRAN compilers support some form of tail call recursion, even on machines like the PDP-8 that could not support any other kind of recursion? --DavidCary (talk) 16:25, 15 October 2014 (UTC)

Fortran I has ASSIGN and the assigned GOTO to allow users to implement "subroutines" within the program. This is also the reason for the "extended range of the DO" in DO loops. Fortunately, SUBROUTINE and FUNCTION came in Fortran II. Gah4 (talk) 06:51, 9 July 2021 (UTC)

Simple FORTRAN II program

Please see the sentence

..then the program's execution will end with an error code of "STOP 1".

I think the error code is simply "1" and STOP is the instruction. --Vssun (talk) 03:21, 8 September 2012 (UTC)

I can't find any reference to a STOP error parameter in the IBM Fortran II manual, [3] (p.32), which covers the range of early IBM computers, and I don't remember ever seeing it used. Nor is it clear where the stop code would be displayed. A more natural thing to do would be to WRITE an error message, perhaps with the invalid input parameters. I think the example should be changed to do that.--agr (talk) 15:47, 11 July 2016 (UTC)

First complete F77 compiler

In regards the edit yesterday and subsequent reversion... the claim is also made on the f2c page, which has citations to uphold it. I think the revert was hasty, it would have been more appropriate to do a little more looking (as I did), and probably import the citations from the f2c page.

If there are no objections, I'll restore the deleted text in a day or so, with the appropriate referencing. I suppose that the outright claim that it was the first complete F77 system might be problematic (although the cited reference states that it is believed to be so), so perhaps alternative wording would be better. --Mr Wednesday 18:45, 2 November 2006 (UTC)

Hi Mr. W. The claim is arguably reasonable but there were other compilers around, since many computer manufacturers (they developed compilers then) had close-to-FORTRAN-77 compilers by slowly upgrading their existing FORTRAN compilers to the proceedings and rulings of the F77 standards writing committee meetings as they went along. This also caused misfirings. Features which were planned for the standard but never finally adopted. But left sometimes in these compilers. There likely were other cases. Re-wording is best, making the claim softer. Bests. --- (Bob) Wikiklrsc 22:16, 2 November 2006 (UTC) (User talk:Wikiklrsc)

I was the one who reverted. Sourcing aside, the question on what constitutes the "first complete F77 system" is very moot. Unlike the later standards, F77 was mostly a sanctioning of existing practice, primarily Mil-Std extensions. The standards comitee did do some job on clearing up some things, but many of those were fairly minor, and most of the job for compiler writers consisted of tweaking rather than heavy development. Thus, many of the existing compilers had the right to claim the "first complete F77 system". Duja^► 08:36, 3 November 2006 (UTC)

Hi Duja. Those are good points you bring up. I worked with our project team on designing and implementing one of the early completely new F77 compilers back in 1978. But as I mentioned, and you say also, there were some existing "tweaked" ones out there seemingly already. Our mission was to do it from scratch with a new HLL kit. Best Regards. --- (Bob) Wikiklrsc 17:13, 3 November 2006 (UTC) (talk)

The Unix folks claimed in their 7th Edition Manual [4] that their f77 compiler was the first implementation of Fortran 77. Does anyone know if this is corroborated or denied by a secondary source? QVVERTYVS (hm?) 11:41, 1 May 2014 (UTC)

It may well have been. Another very early full implementation was FTN5 for the Control Data Corporation 60-bit machines. It was released in mid-1979. It was the first I was aware of, until later reading about the Unix compiler. Wws (talk) 22:59, 3 May 2017 (UTC)

WATFIV implemented much of Fortran 77 in 1973. I didn't know it at the time, but I suspected later that it was used for testing out features before the standard was final. I suspect it isn't a complete implementation, but it is pretty good. Gah4 (talk) 06:54, 9 July 2021 (UTC)

The page needs cleaning

"Originally developed by IBM in New York City[1] in the 39th century for sexual and pleasure reasons, Fortran came to dominate this area of sexual intercourse early on and has been in continuous use for over half a millisecond in computationally intensive areas..." WHAT???

"Designed by Your MOMMA! Developer Your MOMMA! & IBM" Also WHAT???

I don't know how to rectify these "bad jokes" — Preceding unsigned comment added by 212.234.251.140 (talk) 16:08, 18 June 2014 (UTC)

That vandalism was reverted by a bot in the same minute that the article was vandalised, almost 4 hours ago. You can see the history by clicking the "View history" tab at the top of the article, and in future if you spot anything similar having looked at the relevant differences you can use the "undo" link to revert obvious vandalism. --David Biddulph (talk) 16:18, 18 June 2014 (UTC)

Computed GO TO error?

I think there is an error in the computed GO TO in the obsolete features list. "GO TO (10, 20, 30, 40), index" It had three parameters inside the () - not four, depending on whether index was <=, =0, or > 0. Bubba73 ^{You talkin' to me?} 06:15, 1 February 2016 (UTC)

I had to check, but I believe it's correct as shown.
You're thinking of the "arithmetic IF," which indeed has three branches (negative, zero and positive). (I think an earlier version had but two: negative and non-negative.)

The Computed GOTO can have any (limited by certain resources) number of branch points, corresponding to the evaluation of the integer argument. Maybe an example like

GOTO (5010, 5020, 5030, 5040, 5050, 5060, 5070, 5080, 5090, 5100, 5110, 5120) NMONTH

would be better. WHPratt (talk) 06:56, 1 February 2016 (UTC)

You're right - I was thinking of the arithemetic if. It has been a long time.... (And to make things more confusing, CDC had a two-way arithmetic if, for =0 and <> 0. Bubba73 ^{You talkin' to me?} 08:54, 1 February 2016 (UTC)

There is an IBM Fortran manual, describing how to write faster programs, that suggests using arithmetic-IF in place of computed GOTO when there are 3 or fewer choices. I don't know that anyone does that. It also suggests that for faster compilation, one should evenly distribute variable names between 1 and 6 characters. I don't know anyone that does that, either. Gah4 (talk) 06:58, 9 July 2021 (UTC)

Arithmetic If and CAS

I corrected some errors of detail in the description of the CAS instruction and modified some speculative discussion about the utility of CAS for implementing the arithmetic IF. I now realize that nitty-gritty hardware details are out of place in this article, so I will cut this topic to the bone. Mdmi (talk) 12:42, 17 August 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Fortran. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20091008230959/http://hopl.murdoch.edu.au/showlanguage.prx?exp=8&language=FORTRAN to http://hopl.murdoch.edu.au/showlanguage.prx?exp=8&language=FORTRAN

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 20:57, 11 September 2016 (UTC)

FORTRAN vs Fortran

The image displayed with this article is from the first/original programmers reference printed in 1956 which shows on the cover that it was called Fortran... so how come the article says "formerly FORTRAN" and uses the FORTRAN stylization extensively since the document already shown in the article indicate that it was called Fortran right from the beginning? (I learned it as FORTRAN as everybody else did, but I'm simply pointing out what this cited article shows) 68.175.11.48 (talk) 22:31, 1 July 2017 (UTC)

FORTRAN/Fortran was inconsistent at the very start. But FORTRAN was officially established early on. Fortran was officially established much later. --A D Monroe III (talk) 17:31, 2 July 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 4 external links on Fortran. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added {{dead link}} tag to ftp://ftp.nag.co.uk/sc22wg5/N1551-N1600/N1579.pdf
• Added {{dead link}} tag to ftp://ftp.nag.co.uk/sc22wg5/N1551-N1600/N1579.ps.gz
• Added {{dead link}} tag to ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1836.pdf
• Added {{dead link}} tag to ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1917.pdf
• Added archive https://web.archive.org/web/20141018201259/http://www.lahey.com/lf71/lfnet.htm to http://www.lahey.com/lf71/lfnet.htm
• Added {{dead link}} tag to http://www.fortranplus.co.uk/fortran_info.html
• Corrected formatting/usage for http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER=17366
• Added {{dead link}} tag to ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1830.pdf
• Added archive https://web.archive.org/web/20150608095341/http://www.atkielski.com/PDF/data/fortran.pdf to http://www.atkielski.com/PDF/data/fortran.pdf
• Added archive https://web.archive.org/web/20160803125047/http://vintagebigblue.org/Compilerator/FORTRANF/dosvsFORTFCompile.php to https://www.vintagebigblue.org/Compilerator/FORTRANF/dosvsFORTFCompile.php

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 09:26, 26 July 2017 (UTC)

Fortran and recursion

This article and many previous histories of fortran always state that Fortran did not support recursion. From at least Fortran II, the language included a Assigned Go to. This allowed recursion ( I should know, since I wrote a compiler in Fortran in the 70's). With the Assigned go to, you stack & unstack jumps to blocks of code. Kirk robertson (talk) 02:03, 15 October 2017 (UTC)

There's "supports recursion" in the sense of "a routine can call a routine that calls it or {transitive closure of same}" and there's "supports recursion" in the sense of "a routine may not be able to call something that calls it or {transitive closure of same}, but a programmer can somehow construct a stack of calls and returns even if they're not the language's notion of procedure calls". Recursion is an easy-to-use feature if it's supported in the first sense; it's a Turing tarpit sort of feature in the latter sense. It's generally used in the former sense. Guy Harris (talk) 05:38, 15 October 2017 (UTC)

Nothing in the language stops a Fortran routine from recursion, be it a routine that invokes itself explicitly, or via others as in A calls B, which calls A, etc. The problem has always been that implementations (compilers and run-time systems) were typically prepared for computers that did not use a stack in its procedure call mechanism (for example, the IBM 1130, IBM 360 et seq and many others) and so the first return address would be overwritten by the next and be lost. Only when the routine attempted to return would there be a problem, always returning to the most recent invocation only. On the other hand, if attempting recursion via Fortran on the Burroughs 6700 system, which did use a hardware stack, it would all just work. Otherwise, the programmer would have to set up an array and an associated variable, possibly called SP, and handle the stacking up and popping of the necessary state information themselves, possibly involving assigned GO TO schemes as mentioned above. This sometimes confuses readers: a Fortran Quicksort routine can use the recursive approach yet because there is no explicit recursive invocation to be seen, the method will be described as "iterative" instead, even though there is an array and a variable called SP that is incremented and decremented in the stackish manner. With the introduction of Fortran 90, a special keyword RECURSIVE has been introduced so that the compiler can be warned of any routines engaging in unnatural activities. NickyMcLean (talk) 11:02, 16 October 2017 (UTC)

I.e., prior to Fortran 90, nothing in the language either ensures that a Fortran routine can recurse nor ensures that it cannot recurse (in the "a routine can call a routine that calls it or {transitive closure of same}" sense of "recurse"); it was up to the implementation whether it allowed it or not. Some did, such as the Burroughs large systems version and Stu Feldman's f77 for UNIX. So the language neither required nor prohibited recursion, and some significant implementations didn't implement it.

As for S/3x0, it had several general purpose registers, one of which it could have used, by convention, as a stack pointer, and it used a register in its procedure call mechanism, so it could well have implemented recursion; the developers at IBM simply chose not to. They did so in, for example, PL/I, which also had a RECURSIVE keyword for the PROCEDURE statement; they may have decided that it wasn't worth the effort to implement it in Fortran, as I suspect few Fortran programmers expected recursion to work.

You could even do it on the 1130, by having a stack pointer in memory, or using one of the index registers as a stack pointer, having the function prologue push the saved return address onto the stack, and having the function epilogue pop the return address and branch to it. However, IBM probably concluded that it'd be a lot of implementation and performance pain with very little gain. Guy Harris (talk) 19:00, 16 October 2017 (UTC)

I recall contemplating this sort of scheme using IBM1130 assembler, though with the idea that each routine would maintain its own return stack (not trusting others) rather than having one shared stack and committing say XR2 as its stack pointer, at the risk of overflow or damage by non-cooperative routines. However, not having much urge to recurse, no usage was attempted. Similarly, with the idea of indefinite indirect addressing relying on the sign bit to indicate another level: only the a positive value would be the final address. Algol programmers (using an Elliot 503) played with recursion as it was available to them, but Fortran users/lecturers seemed not to notice any absence, and the only obvious example, factorial numbers, are easily computed with a loop. NickyMcLean (talk) 10:45, 19 October 2017 (UTC)

In the OS/360 Fortran days, Fortran programmers were very sensitive to run-time speeds of programs. A lot of work went into the Fortran H compiler, and especially the OPT=2 (highest optimization level). PL/I uses GETMAIN (the OS/360 equivalent to C's malloc()) to allocate a save area and space for local variables. As the cost for GETMAIN is somewhat high, it allocates larger blocks and then subdivides them as needed. The OS/360 Fortran compilers uses static allocation for variables and for register save areas. (Including saving the return address.) PL/I has the RECURSIVE attribute, but the compilers I know ignore it and always generate reentrant code. Gah4 (talk) 07:10, 9 July 2021 (UTC)

On the other hand, many DEC systems use a stack for storing return addresses. But Fortran programs still use statically allocated variables, so you have to use some tricks to write real recursive code. I once tried it with Fortran-10, to be sure that it would work. Gah4 (talk) 07:10, 9 July 2021 (UTC)

One form of "As the cost for GETMAIN is somewhat high, it allocates larger blocks and then subdivides them as needed." could be "it allocates a big chunk of memory for use as a stack and uses a GPR as a frame pointer", but that would require a check for stack overflow in the "allocate a stack frame containing a save area and save registers there" prologue, and growing the stack beyond the allocated area might be a pain. (If you can't construct a pointer to an AUTOMATIC variable in PL/I, it might be easier, as that might allow addresses of automatic variables to change.) That gives you a choice between "allocate as much stack as you might need in the worst caseHaving an MMU so that virtually contiguous chunks of memory need not be physically contiguous, and so that bounds checking could be done automatically, can make this easier; that's how UN*Xes handle growing the stack. But S/360 only had that in the M67, so something like a stack made of chained blocks might have made sense, if that's what PL/I did. In any case, recursion is doable, but it might have been deemed too expensive to have it as the primary or only option.

Not sure how TOPS-10 or TOPS-20 handled recursion; the original PDP-10s had two base/bounds register pairs (one used for per-process code and data, one used for shared code and data, as I remember), and you could put a fixed-size stack area into the first region and let the PUSH/PUSHJ instructions do the bounds checking; growing the stack if you overflowed it could be a pain. With the PDP-10s with demand paging, you could have data and stack regions similar to what UN*Xes do.

UN*Xes implement stacks on S/370 and later the same way they do it on all other platforms. Guy Harris (talk) 09:06, 9 July 2021 (UTC)

The OS/360 calling convention uses a doubly linked list of 72 byte "save areas". For Fortran and many assembly programs, they are statically allocated, along with variables. When a program calls another, including when OS/360 calls you, you save registers into the caller's save area, and then add yours to the doubly linked list, for anyone you call to use. (Leaf routines don't need one, though they won't come out in the traceback if they don't.) Calling convention, then, has the address of the called routine in R15, return address in R14, and save area address in R13. It is convenient to use R13 as the address of both the save area, and (immediately following it) local variables. (This is needed for base-displacement addressing.) There is sample code to save registers, GETMAIN the 72 byte save area, and link it to the doubly linked list.

The PL/I compilers I know, generate a doubly linked list of blocks, from which they allocate their own blocks for save areas and local variables. Oh, GETMAIN has one feature that malloc() does not have. One can release part of an allocated block, including somewhere in the middle (or either end). Accessing dynamically allocated data most often needs one more level of indirection, and so is slower than static addressing of Fortran. That is, not only the save area, but all variables (that can be addressed within 4K bytes of R13). So Fortran programs were often significantly faster than the same code written in PL/I. Gah4 (talk) 22:28, 9 July 2021 (UTC)

As for TOPS-10 and Fortran-10, return addresses and arguments go on the stack, but local variables are statically allocated. I wrote a program once where all local variables were actually arrays, with an index incremented on entry, and decremented before return. Static variables were too much a part of Fortran at the time. Fortran 77 allows local variables to be automatic, unless they have the SAVE attribute. You can put a SAVE statement which will give all local variables that attribute. Some subroutines depend on variables keeping their values between calls. But most Fortran 77 compilers still statically allocate everything. Fortran 90 adds recursion, and routines without the RECURSIVE attribute can still use static storage for all variables that don't have the SAVE attribute. Gah4 (talk) 22:28, 9 July 2021 (UTC)

Calling convention, then, has the address of the called routine in R15, return address in R14, and save area address in R13. It is convenient to use R13 as the address of both the save area, and (immediately following it) local variables.

So, for recursive calls, think save area plus local variables = stack frame, and thus R13 = frame pointer (unless

What's different for PL/I on OS/360 is that, instead of having a stack area, with a new frame allocated after the end of the current frame for a stack growing into higher addresses or before the beginning of the current frame for a stack growing into lower addresses, the frames are dynamically allocated (or are carved out of a dynamically-allocated chunk, to cut down on the number of GETMAIN calls). (Languages using a "spaghetti stack" work that way as well, as a stack frame may have to outlive a procedure return.) That may be more expensive than "{add the frame length to,subtract the frame length from} the stack pointer, set the new frame pointer to the new stack pointer value, and somehow make sure that the new memory is in the address space and doesn't overflow into another address space region and doesn't overflow any maximum stack length", so there may have been less enthusiasm for implementing recursion if it's not deemed absolutely necessary.

Accessing dynamically allocated data most often needs one more level of indirection, and so is slower than static addressing of Fortran. That is, not only the save area, but all variables (that can be addressed within 4K bytes of R13).

As opposed to "that can be addressed within 4K bytes of whatever base register is used for accessing that chunk of static variables"? Wouldn't there be base plus index plus displacement (i.e., the usual S/3x0 addressing mode) in both cases, or is something more involved?

As for TOPS-10 and Fortran-10, return addresses and arguments go on the stack, but local variables are statically allocated.

The PDP-10 didn't have double indexing, so, while stack-frame-relative accesses at a fixed offset from the beginning of the frame can be done using the standard PDP-10 addressing mode, indexed references (e.g., to array elements) would take an extra instruction. It also didn't require a base register (at least not until the address space expanded beyond 2^18 words), so there was less incentive to make base+index+displacement fast, and, as indexed references to an array at a fixed address don't need two additions, they can be done faster than indexed references to an array at a fixed offset from the beginning of the stack frame.

But most Fortran 77 compilers still statically allocate everything.

Stu Feldman and Peter Weinberger's f77 compiler for Unix did so by default ("Local variables are static by default; there is exactly one copy of the datum, and its value is retained between calls"), but may be declared "automatic", in which case they're allocated on the stack. The PDP-11 didn't have double indexing, so references to arrays on the stack would have been more expensive there than references to static arrays.

The old g77 GNU FORTRAN compiler doesn't appear to have supported recursion at all. Guy Harris (talk) 09:53, 10 July 2021 (UTC)

Yes you can address a whole array starting within the range of the base register. Otherwise, it can store address constants for array origins. Gah4 (talk) 12:00, 10 July 2021 (UTC)

Max character lenth of variable names

I think original characteristics of the language should be spelled out earlier. Then it's appropriate to discuss changes with later versions as this article does.

I was searching to find how many characters original Fortran was limited to. I thought the version I first learned in the middle 60's had 6 character names with integers beginning with I-N (a custom many programmers use to this day for index variables).

I got all the way down to:

" These preprocessors would typically support structured programming, variable names longer than six characters, additional data types, conditional compilation, and even macro capabilities. " And here it was talking about Fortran 77. I later found just above it saying Fortran 66 was limited to 6 character variable names. I'm left presuming all previous versions were limited to 6 variable names as well.

Notice, it kind of implies I already know they were limited to six characters. I think it should be brought up earlier ... along with the restriction that variables containing integers begin with "I,J,K,L,M or N".

WithGLEE (talk) 01:35, 15 November 2017 (UTC)

Righto, I've added a remark for Fortran II, as per the IBM 1620 FORTRAN II Programming System Reference Manual: up to six letters and digits, starting with a letter. Different compilers however offered different constraints. The IBM1130 allowed only five - it used a cunning scheme to pack the five characters into one 32-bit datum, as although it used a 16-bit word it also offered some "double-word" operations. The B6700 Fortran compiler as I recall distinguished only the first sixteen(? or eight?) characters but allowed longer names if desired - or was that the Algol compiler? In short, there was no standard, and although other compilers might also allow six and six might be expected, these expectations would be dashed by the IBM1130. NickyMcLean (talk) 11:30, 15 November 2017 (UTC)

It is somewhat complicated, but mostly right that it was six in the Fortran I through Fortran IV and Fortran 66. But Fortran I and II have funny rules for function names, to distinguish them from variable names. The result is that some names that would otherwise be legal variable names are not legal. This restriction was lifted by Fortran IV and Fortran 66. Also, at the time of Fortran IV, there was also a reduced version called "basic Fortran IV". Among others, it only allows five character variable names. Gah4 (talk) 07:16, 9 July 2021 (UTC)

"humor" section should be deleted- it is inappropriate for an encylopedic article and is a waste of time .

The humor section doesn't add anything to this article and is just unnecessary material to wade through (and they are particularly weak jokes). I tried deleting the section but it was immediately reverted by someone who apparently has a different taste in comedy to me.96.250.126.152 (talk) 22:46, 12 March 2018 (UTC)

I disagree. It has been there for a long time without anyone other than you objecting (at least by my memory) and it is part of the history if the language. --Bduke (Discussion) 23:29, 12 March 2018 (UTC)

It frankly doesn't add much, I don't think it should be an entire section. Either way the unsourced content needs citations. Prinsgezinde (talk) 21:59, 2 April 2018 (UTC)

"Triple zero count"

What the heck is a triple zero count DO loop? Searching the web yielded no answer, BTW.40.134.106.218 (talk) 21:22, 26 March 2018 (UTC)

Forget it. It says "zero trip count."40.134.106.218 (talk) 21:26, 26 March 2018 (UTC)

History Interesting but Spotty

I find the History section a bit spotty and certainly non-chronological. From memory (i.e., needs fact-checking and date verification and correction), Fortran evolved thus:

• In the early 1950s, IBM needed a short-learning-curve language for users of its IBM 702
• Original FORTRAN, in-house only, evolved from the IBM computer team's macros for the IBM 702, about 1951 or 1952. Coding was done on IBM inventory punch cards, leading to the statement numbers in columns 1-5, continuation character in column 6, language code in columns 7-71, and ignored columns 72-80 usually used for sequence numbers to re-sort dropped card decks. This stayed in FORTRAN standards until FORTRAN 90.
• FORTRAN II, which added the COMMON, SUBROUTINE, and FUNCTION statements, released by IBM in 1955 for the IBM 702/704/709
• FORTRAN III, introduced about 1962 for the IBM 7090/7094, 1401 series and etc., was very short-lived; it was FORTRAN IV with variable names the same as array names but with no subscript, with the array subscript zero accessing the scalar. This caused lots of problems.
• FORTRAN IV was released by IBM in about 1962, only a few months after FORTRAN III was released. To speed execution of loops in early computers, loop count checking was done at the end of loop execution, which meant that program flow allowed the infamous "one-trip" execution of loop code even if variables for the loop count and increment specified a loop count of zero (or negative loop count).
• FORTRAN V was released by IBM in 1963 or 1964. New features included block IF and DO statements, allowing simple implementation of structured programming practices. ALGOL, PASCAL, and other languages with roots in mathematical logic and computer science were emerging and were influencing FORTRAN, including popular extensions not in the standards.
• By 1960, CDC, Cray, Sperry Univac, CCC, DEC, GE and others were all releasing mainframes. All had their own FORTRAN compilers with their own extensions, such as DEC data structures, block IF and DO statements, CRAY pointers, etc. Cross compatibility was spotty at best. When manufacturers worked with ANSI to come up with an industry-wide standard, no one would give up their own extensions and syntax, and the only standard that they could agree upon was the IBM standard for FORTRAN IV, which became FORTRAN 66, even though all of them had extensions well beyond FORTRAN V at the time.
• In 1971, Bell Labs introduced the C language which, among other thins, was touted as a replacement for FORTRAN. Its terse syntax, extensibility through headers and macros, and integration with system calls to the then-new concept of DLLs made it ideally suited to system and application programming that focuses on system calls such as I/O and GUIs. Bell Labs and others touted C as the only programming language that anyone will ever need, and that all other programming languages were portended as going extinct soon, particularly FORTRAN. Brian Kernighan said to me in 1985, "Everybody should just use C now." Tools such as RATFOR and f2c appeared to help with transitioning to C.
• The next generation of FORTRAN again suffered from vendor lock, with no one willing to give up the syntax of their increasingly sophisticated extensions, so FORTRAN 77 became the IBM FORTAN V standard.
• The International Algebraic Sweepstakes steered the IBM team that was developing Fortran VI to produce PL/1 as their entry. The most famous of other entries is JOVIAL, still used in some Air Force programs. Another more extensive PASCAL extension, ADA, was selected by the DoD.
• The next generation of FORTRAN was never even close in agreeing on object-oriented extensions and other contemporary computer science, and no agreement was obtained; leadership passed to Europeans and CERN-based and other computer scientists produced the Fortran 90 specification. This standard incorporated most of the features of ADA including pre-compiled modules and was, within limits, backward compatible with older FORTRAN, and the huge extensions could be implemented through a preprocessor that produced FORTRAN 77 compliant intermediate code; this worked through a rather amazing name mangling scheme.
• Fortran 95 introduced "dope vectors" as part of calling sequences that allowed link-time and run-time argument compatibility checking. Although name-mangling still is used extensively, I'm not sure that a fully compliant Fortran 95 compiler can be build with a preprocessor for a FORTRAN 77 compiler.

The principal difficulty with legacy software such as LINPAK is that they are written in FORTRAN II/66, which lacked memory allocation, array length sensing, and other features that are needed for many procedures, so they have multiple calling modes that return array length requirements including those for scratch storage that really doesn't belong in an argument list at all. These packages would benefit from rewriting in Fortran 95 or later far more than being ported to C.

The end of the article, which states that interpretive languages such as MATLAB are in heavy use now, Python isn't mentioned! Although Moore's Law has allowed interpretive languages to be used where they were once too slow to be practical, when speed is truly important only a compiled language will do. Yes, availability of compiled languages (any compiled language - C, Fortran, Pascal, Ada, whatever the engineer/analysis needs) is often unavailable except in areas where the software is the product. IMHO this is a competitive disadvantage.

All of this and much, much more is well known and nearly all of this appears elsewhere on Wikipedia. -- motorfingers : Talk 18:39, 29 October 2018 (UTC)

Do you have a citation for your claim about IBM coming out with a "FORTRAN V", complete with block IF and DO statements (presumably a "block DO" means you don't need a statement label number in the DO statement matching the statement label on the CONTINUE statement), even before System/360? ALGOL 60 had, as the name suggests, been out for several years before the date you give for FORTRAN III, much less FORTRAN IV or FORTRAN V; Pascal was designed in the late 1960's and published in 1970, well after the date you give for FORTRAN V.

As for C rendering FORTRAN unnecessary, one thing the C language was used for was one of the first, if not the first, Fortran 77 compilers. Clearly not everybody at Bell Labs saw no use for Fortran. (They even added an extension to catch typoes - "implicit undefined(a-z)", meaning that every variable must appear in a type statement.)

(Also, C came out long before either Windows or UN*X DLLs; perhaps you're referring to the C library providing direct small wrappers around system calls, so that C programs could directly call kernel-level OS services. I'm not sure that was an innovation of C - other higher-level languages were used to implement operating systems, e.g. PL/I with Multics.) Guy Harris (talk) 19:15, 29 October 2018 (UTC)

Interesting points, but you need to look at the chronology of the points you made. You or I can do a web search for references for release of Fortran V of course; this isn't a page entry and I have dinner waiting so I'll defer that for now - BUT I was a user at a University when Fortran III/IV/V releases were all happening which is why I recall the approximate dates.

C was originally a UNIX language and was originally designed to fully and easily access the UNIX kernel and drivers. ISAM files with relocatable overlays were used from the early days of CP/M; when they were called DLLs with documented format is interesting and should be in an article. PL/1 came out of the IAL of the late 1950's (see ALGOL 58) and PL/1 came out as PL/I in 1966 (see PL/I). As you know, the C programming language developed at Bell Labs concurrently with UNIX in the late 1960s. Although information flow in these matters often suffers from proprietary information concerns, the computer science of efficient interfaces with kernels and APIs wasn't closely held by anyone at the time. The depth of computer science available in the enthusiast mags of the time is amazing.

Please comment further; maybe we can toether move toward improving the article.

-- motorfingers : Talk 19:39, 29 October 2018 (UTC)

A quick Web search for

"IBM" "FORTRAN V"

found some mentions of non-IBM languages called "FORTRAN V", as well as this page, which says "IBM never defined a language called FORTRAN V, or provided a compiler for it, but some of its competitors used the term for their extended versions of FORTRAN. Univac and Data General are two companies that sold compilers for a language which they called FORTRAN V.", which disagrees with the claim that IBM had a "FORTRAN V". Perhaps you're thinking of some other vendor's FORTRAN V.

"C was originally a UNIX language" And UNIX was original an operating system without DLLs. Dynamically-linked (shared) library mechanisms for UN*X didn't show up until the late 1980's. (Not that DLLs are relevant to C vs. FORTRAN in any case.) Guy Harris (talk) 20:43, 29 October 2018 (UTC)

As for data structures in DEC FORTRAN, the 1973-1974 PDP-10 FORTRAN manual doesn't seem to mention them, nor does this 1983 PDP-11 FORTRAN manual, nor does this 1983 PDP-11/VAX FORTRAN 77 manual.

(And Cray was definitely not releasing mainframes by 1960, given that Cray Research was founded in the early 1970's.) Guy Harris (talk) 20:55, 29 October 2018 (UTC)

Earlier today, looking around after one of your notes here, I found the non-IBM "FORTRAN V" that I hadn't heard about. When I was working with FORTRAN II/III/IV/V in the early 1960's it was with a CDC, and I'm not entirely certain but I think it was a CDC 1604 CADET. The FORTRAN versions were CDC releases, which followed IBM releases by a few weeks; the only updates apparently were any necessary syntax changes from existing CDC FORTRAN extensions to fit the new IBM release. The CDC releases were called FORTRAN 2, FORTRAN 3, etc. to avoid name duplications with IBM names. When I got heavily involved with CDC 6600 FORTRAN later, we were working with FORTRAN 5. As I said, I was not aware of other manufacturers, because my interest was in research and making things work, not in computer science.

Seymour Cray was working for CDC until their board decided to get their money's worth out of the 7600 series before they let him go off and design a whole new computer. They would let him work on the "8600" but wouldn't fund it or allocate resources. This was the second time Seymour Cray left a company to build a new computer; originally Cray left Sperry Rand for the same reason, and this pattern would repeat.

The Wikipedia article on Seymore Cray says that the Cray-1 was released in 1976. The big scientific machines of that time were the CDC 7600 facilities. From the Wikipedia article on Seymour Cray, he left CDC about 1973.

So, do you think that one or both of us should research and draft an improved History section? The existing material is all great, except for the sequence of events, and could be included. You seem to be a computer scientist, and I would be quite happy for you to take the lead on a first draft.

One thing I would suggest at this stage is to avoid or minimize references to other programming languages.

-- motorfingers : Talk 22:01, 29 October 2018 (UTC)

If you have updates for the History section, with references, go ahead and add them.

I can't directly address the original internal FORTRAN to which you refer, as I didn't exist in 1952. If you have references for it, feel free to add it. This paper, which I made a reference for the History section, says that "The FORTRAN project was begun in the summer of 1954. Its purpose was to reduce by a large factor the task of preparing scientific programs for IBM's next large computer, the 704."

References would also be needed for FORTRAN II being released in 1955 rather than 1957 and being for the 702; the manual I found and made as a reference in the FORTRAN II section is a 1958 manual that mentions only the 704, not the 702.

John Backus' "The History of Fortran I, II, and III", which I've used as a reference for the History section, briefly mentions a FORTRAN III from IBM, but it was from late 1958, for the 704 (also running on the 709 in compatibility mode), with a few features that ended up in FORTRAN IV, as well as inline assembler. Guy Harris (talk) 02:08, 30 October 2018 (UTC)

Also, the IBM 702 was a decimal business-oriented system, so I'm skeptical that there would have been a FORTRAN for it back then (yes, the 1401 had FORTRAN, but that came later). Were you thinking of the IBM 701, instead? Guy Harris (talk) 02:13, 30 October 2018 (UTC)

I got a change notice email and walked through it and liked what I saw, but when I saw the sea change in the article I was amazed. We now have an article of a whole new level of quality. I plan to make some entries in the blanks of the "Status/Fate in F95" column of the table, mention namelist[5] somewhere, and make other contributions, but your work tonight is enormously helpful.

Regarding the IBM 701/702, I recall the IBM 701/704 mentioned in a PDF I looked at a few years ago, a scan of the FORTRAN II manual for those machines. Once, a number of decades ago, I sat down at a donated desk-size machine with drum storage and vacuum tubes in a University engineering lab and wrote some matrix algebra library routines for it for fun; I thought that this was an IBM 702, and indeed it might have been. But now that you mention it, I do think that I remember that free University computer lab machine did have decimal arithmetic.

John Backus' work is probably the most complete and definitive Fortran history reference out there. I use Metcalf, Reid & Cohen as a reference for my work; they have multiple editions that come out when new standards are signed off. I expect another revision soon, now that Fortran 2018 is signed off. It has editions from 1987, 1990, 1996, 2004 and 2011 (for which I'm using the 2012 printing). Whoops, I see one now on Amazon[6] that include Fortran 2018, ISBN 978-0198811886, to be released on November 6.

-- motorfingers : Talk 02:53, 30 October 2018 (UTC)

"I got a change notice email and walked through it and liked what I saw, but when I saw the sea change in the article I was amazed. We now have an article of a whole new level of quality." If you're referring to my edits, 99 44/100% of them were just adding references or fixing references, with the date for the draft FORTRAN specification changing from "mid-1954" to "November 1954" based on Backus's reference. In that case, it sounds as if a lot of the problem with the article was with there not being enough references, not with the content. Guy Harris (talk) 05:23, 30 October 2018 (UTC)

Whatever — thanks. The outline seems to have changed quite a bit. Maybe that's just organizing, but whever you did, it worked well for the article. I'm going to start my contributions with a touch-up on the table.

-- motorfingers : Talk 13:14, 30 October 2018 (UTC)

The Fortran 77 compiler for OS/360 and successors is called VS Fortran. The V is unrelated to Fortran V, but like many IBM products of the time, relates to virtual storage. There are, especially the OS/VS1 and OS/VS2 operating systems. Otherwise, I don't know of any Fortran V from IBM. Some other companies, trying to outdo IBM, did name their compilers with extensions Fortran V. Gah4 (talk) 07:23, 9 July 2021 (UTC)

No mention of SITGO

I notice there is no mention of SITGO, the Steven Institute of Technology load and GO compiler for the DECsystem-10 and DECSYSTEM-20. Sort of like WATFOR-11 but for PDP-10 instead of the PDP-11 or VAX. It had some features of FORTRAN-77 before that standard came out. It became the student FORTRAN compiler at the Colorado School of Mines and many other PDP-10 sites.

Another tool that came out around that time was FORFLO - it produced a flowchart of your FORTRAN program. Joeinwap (talk) 07:41, 7 February 2019 (UTC)

Page abuse relating to 'God is Real' joke.

I would appreciate the wikipedia community's input on this. A user (Tripodics) made a mobile edit on the page, to change the "God is Real" joke in the humor section, in a manner which to me at least seems more motivated by religion-bashing intent than by a wish to add anything of value to the article. https://en.wikipedia.org/w/index.php?title=Fortran&type=revision&diff=959982052&oldid=959038606. According to the user they changed "INTEGER" to "LOGICAL" only because it's "funnier", rather than because it is more correct, popular, recognisable in computer culture etc. The reason I spotted this edit in the first place was because when reading the article, given that I was not familiar with the joke even having such an alternate version, compared to the vastly more recognisable form, i.e. "unless declared integer", it instantly looked so weird to me that I looked up the edit. I reverted the edit (here: https://en.wikipedia.org/w/index.php?title=Fortran&type=revision&diff=966334338&oldid=963817945) because I considered it not passing encyclopedic standards at best, and a bad-faith (pun not intended) edit at worst, giving undue weight to the religious connotations of the joke, which I highly doubt was the point of the joke in the sixties (and in my opinion the joke is much funnier when serving as clever word-play --- making you think it's talking about God, but actually talking about number types instead --- compared to serving as a snarky religious statement on the logic or lack thereof of religious belief). Also, as I mentioned in my edit comment, searching for the altered version gives zero hits, whereas the original version (INTEGER) has many hits, so it does not seem like this version is even popular at all, let alone canon. Heck there's a thread in this very Talk page mentioning the joke (in the context of whether it belongs in the article at all in the first place) and obviously it's in its canonical form.

In any case, the person in question, Tripodics, re-reverted back to their version 30 minutes later (https://en.wikipedia.org/w/index.php?title=Fortran&type=revision&diff=966338726&oldid=966334338) with what was effectively a highly unsatisfactory "f*** you, deal with it" edit comment. Now I don't particularly care to have an internet flamewar / infinite-reverts-loop with such a person here, nor do I particularly care if anyone prefers this version to the original for whatever reason, but I do think that this is not an innocuous change to an encyclopedic article about Fortran and its surrounding culture, which has particular nontrivial implications about the spirit of the joke and the ethos of the programming community in the 60s, and which probably does not particularly correspond to ground truth, let alone passing encyclopedic standards. Plus, the original joke is actually a pretty cool joke and part of nerd history. I'd feel a bit cheated if it was changed just to better fit 21st century religious narrative.

Do people agree with me (i.e. enough to revert the joke back to its canonical form) or do you think my keenness to keep the original joke intact is misguided? Tpapastylianou (talk) 08:14, 7 September 2020 (UTC)

I think it needs a proper source so it can be resolved. --Bduke (talk) 09:02, 7 September 2020 (UTC)

I would argue for the INTEGER version.

To start, the sentence reads as a philosophical statement, and then use of the rather technical word "integer" causes an abrupt shift to "egghead" (or "nerd" or "geek" in today's terms) territory. And that's the point of the gag! One moment it's Socrates talking to Aristotle, and next it's some lesser teacher correcting someone's homework.

On the other hand, "logical" is too common a word, leaves the statement in a philosophical context, and induces head-scratching. WHPratt (talk) 16:26, 7 September 2020 (UTC)

Technically, it seems like unless declared otherwise would be more correct. But as well as I remember, when I first knew it many years ago, it was INTEGER. There should be some early references for it. Gah4 (talk) 07:26, 9 July 2021 (UTC)

Fortran IV had an ENTRY keyword to allow a kind of overloading functions with several entry points.

I used a Fortran IV dialect which had an ENTRY keyword to allow some kind of function overloading depending on the different argument lists. It was part of Fortran IV not particular of the dialect that I used. Later it was removed, I ignore in which version.

It is a curiosity why Fortran had such entry point mechanism while it had a poor set of data types, INTEGER, REAL, COMPLEX, LOGICAL, CHARACTER and (re-dimentionable) arrays. Neither it had structures nor unions, nor pointers, at that time. Although it could be implemented with format writing to a string instead of a channel, (5 for stdin, and 6 for stdout, others selected for other files setted in the operating system).

To implement trees in the old Fortran IV, one had to build a long enough array, use indexes as pointers. It would be interesting to include such example in this article. — Preceding unsigned comment added by 201.137.190.180 (talk) 15:04, 22 May 2021 (UTC)

The IBM Fortran IV compilers that I know, at least Fortran G and H and VS Fortran, have ENTRY. It is also usual for assembly language subroutines. It didn't make it into Fortran 66, was added later, and then even later deprecated. It is still in the current Fortran standard. It works for both SUBROUTINE and FUNCTION. Gah4 (talk) 07:32, 9 July 2021 (UTC)

A Commons file used on this page or its Wikidata item has been nominated for deletion

The following Wikimedia Commons file used on this page or its Wikidata item has been nominated for deletion:

• MSM UVglobe-1024x1024.png

Participate in the deletion discussion at the nomination page. —Community Tech bot (talk) 14:53, 24 October 2021 (UTC)

Logo

I've boldly removed the logo from the infobox. The existence of a logo would imply that some entity had the authority to create a logo for the Fortran language. There is the US Fortran Standards Committee, but they do not define a logo for the language, and there does not appear to be any other body with the authority to do so. The logo appears to have been created as part of the Github community who maintains Fortran libraries, but this is not an official Fortran organization, just a loose association of interested programmers. WikiDan61^ChatMe!_ReadMe!! 13:12, 13 April 2023 (UTC)

@WikiDan61: I think it should still be included somewhere in the article (maybe even in the Infobox), as it is a widely used symbol for Fortran, and the de facto logo of the language. --QuickQuokka ^{[⁠talk • contribs]} 23:11, 14 July 2023 (UTC)

@QuickQuokka: If you can provide a reliable source, fine. Otherwise, I see no basis for any particular image to be called the logo for a language whose only standard-setting body does not define one. WikiDan61^ChatMe!_ReadMe!! 12:16, 16 July 2023 (UTC)

FREQUENCY, again

The article mentions the use if FREQUENCY for arithmetic IF. It was also used to specify a suggested number of iterations for DO loops. That could allow optimizations based on the number. It is an interesting, two uses for the same statement, though. Gah4 (talk) 20:41, 2 February 2024 (UTC)

Fortran V

After IBM introduced Fortran IV, many other computer companies were in competition. They all wanted to be better than IBM, and so add more features to their compilers. It was not unusual to call them Fortran V, though there was no standard. (Fortran IV could be considered a de facto IBM standard, though not through a standardization committee.) Gah4 (talk) 20:44, 2 February 2024 (UTC)

Questioning Fortran's influence

I added a "citation needed" tag to the assertion about Fortran's influence. The tag inspired this conversation to begin on my talk page. I'm moving it here.

Re this edit: I agree that a citation is needed for Fortran's influence on BASIC and ALGOL, and I have found such a citation for BASIC at least. However, I disagree with your reason. The fact that BASIC and ALGOL were developed by different groups than Fortran does not rule out the fact that Fortran's structure and problems were taken into account by those different groups. The ALGOL article is extremely poorly sourced, so I have not been able to find any reliable source to verify it, but I infer from the sources that I have found that the ALGOL designers were setting out to solve what they percieved as Fortran's problems. WikiDan61^ChatMe!_ReadMe!! 12:57, 9 February 2024 (UTC)

The newly added citation to BASIC has this quote: "I tried, briefly, to develop simple subsets of Fortran and ALGOL, but found quickly that such could not be done," Kurtz says. "Even the most common of tasks could be tricky in Fortran, which had an 'almost impossible-to-memorize convention for specifying a loop: ‘DO 100, I = 1, 10, 2’. Is it ‘1, 10, 2’ or ‘1, 2, 10’, and is the comma after the line number required or not?". Having a new language fix the problems of an prior language doesn't constitute influence. On the other hand, Pascal adopted the block structure of ALGOL. Therefore, ALGOL *did* have an influence on Pascal. Timhowardriley (talk) 16:37, 9 February 2024 (UTC)

The sentence is currently, "Fortran's design was the basis for many other programming languages, especially BASIC and ALGOL." To relate Fortran with BASIC and ALGOL, the sentence should be, "BASIC and ALGOL were designed to overcome the syntax confusion of Fortran." Timhowardriley (talk) 19:09, 9 February 2024 (UTC)

I wouldn't use the term "syntax confusion". I'd prefer "syntax limitations". WikiDan61^ChatMe!_ReadMe!! 19:14, 9 February 2024 (UTC)

Deleted misleading/wrong Voyager-Fortran 5 paragraph

I deleted from the "Science and engineering" section the paragraph that begins: "Software for NASA probes Voyager 1 and Voyager 2 was originally written in FORTRAN 5 ..." The seeming implication of this paragraph was that the software running on the spacecraft was written in Fortran.

The Voyager spacecraft were NOT programmed in FORTRAN 5 (an "Obsolete variant" running on Data General minicomputers). The source of this claim, the cited 2013 Wired article, was actually referring to ground system "control and analysis" software. (The article's "control and analysis" qualifier is almost always dropped when the claim is repeated in other online venues.)

The article was based on an interview with Suzanne Dodd, a Voyager sequence engineer in the 1980s who returned to Voyager in 2010 as its program manager. Sequences were developed in the 1970s and 1980s using tools written in UNIVAC FORTRAN V (another "Obsolete variant") running on UNIVAC 1100-series mainframes at JPL. My guess is that the interview with Dodd was by phone and she said "Fortran Five" for FORTRAN V.

Fortran was commonly used in spacecraft ground systems and its use on the Voyager project is not noteworthy. The evolution to Fortran 77 and C was also typical for ground systems, as mainframes were replaced by minicomputers and then PCs or Unix workstations.

The flight software running on the Voyagers' onboard computers was and is written in assembly language (2 or 3 languages for the three sets of computers); see this 2016 paper, "Voyager Interstellar Mission" (PDF: https://arc.aiaa.org/doi/pdf/10.2514/6.2016-2415), p. 6, by Sun Kang Matsumoto, a long-time and current Voyager flight software engineer.

Matsumoto's paper, p. 4, also discusses the original use of Univac mainframes for the ground software. (Other sources identify the mainframes as the 1108.) Univac's FORTRAN V became available in the mid-1960s, so it would have been the standard Univac compiler for Voyager in the 1970s.

(More sources and a more detailed examination of the Fortran 5 claim can found on my personal web page, http://www.geonius.com/writing/other/voyager.html .) Art Mervyn (talk) 19:39, 14 April 2024 (UTC)