7 ms·

A Summary of Fortran [pdf] (1992)

39 points by CTOSian 5y ago

Bostonian 5y ago
Old content (this is from 1992) should have a year in the title. This is a summary of Fortran 77. The latest standard is Fortran 2018, and Fortran 202x is being worked on. Some features of Fortran 2018 have been implemented in compilers. For current information on Fortran one should visit https://fortran-lang.org/ https://fortran-lang.org/ .
- hatmatrix 5y ago
  I find it remarkable that modern Fortran implements many advanced features while remaining backward compatible with Fortran 77, which, visually, looks like a different language.
  - jabl 5y ago
    Fortran 90 introduced 'free form', a more modern syntax compared to ye olde FORTRAN. Typically free form source code is denoted by a '.f90' extension whereas '.f' is for the old style fixed form.
    - sampo 5y ago
      It is weird that Fortran was modernized 30 years ago, but the old prejudicies live on. Maybe programming languages teachers in CS departments are now telling their students the same jokes "look how primitive FORTRAN is" that their own teachers told them a generation earlier. So the primitive FORTRAN 77 lives on in Computer Science lore, while Fortran 90/95/03/08/13 is what people in the actual number crunching community use. Let's wait until 2050s and see, whatever Fortran 2050 will be like, if CS people will still joke about Fortran as if it was FORTRAN 77.
      - BlackFly 5y ago
        People will joke about the primitiveness of Fortran as long as they are required to preface every module and program with `implicit none`. Also, every time they pick up lapack and need to specify the "leading dimension of A" they will recall how Fortran had it's roots in a language without dynamic memory allocation and how they're still living with that legacy. Fortran's legacy leaks all over the place: you rapidly get a feel that it is something which is old and creaky, even if it is actually old and rock solid. The ergonomics are very much not modern, though, but as with all discussions of ergonomics, that is going to depend on how you like to hold your tool. Not that other languages which have widespread support also have similar historical mistake leakage. Null vs Optional in Java comes to mind. The python 2 -> 3 debacle was a similar sort of "historical mistake correction" but the breakage of backwards compatibility lead to quite some polarization. Actually, in python 2 -> 3, the python core developers tried to fix a historical defect that fortran still has: print as a keyword vs a function.
        theodorethomas 5y ago
        <as long as they are required to preface every module and program with `implicit none`> A small price to pay for being able to run code from 60 years ago. And no, there is no such requirement as such. <need to specify the "leading dimension of A"> A very clever way of applying your algo to a submatrix from the days of sequence association and no array expressions. Nothing to do with dynamic memory allocation and you know the compiler will have no excuse to copy data. Why is it a defect that I/O needs keyword? Fortran has doubled-down on that "defect" by making coarray references through syntax [] and not an MPI-like procedure call. I don't think it's a defect at all, it's a strength.
        BlackFly 5y ago
        I really don't understand why you're arguing with my explanation. I'm not attacking fortran, I'm explaining why it will feel old to people: because it has things in it that people moved on from. Heck, I'd even agree that it is a sort of bad attitude to automatically discount something because of such legacy. But there are clear historical artifacts in the language (like most languages today). > A very clever way of applying your algo to a submatrix from the days of sequence association and no array expressions. This isn't why you specify the leading dimension, it is just a useful feature of the leftover artifact of the lack of dynamic allocation. If the algorithms were written today, the array slicing notation would simply be used to achieve that. Back in Fortran 66 days, you would compile a large 2d array to solve the biggest problem you wanted to solve because you couldn't dynamically allocate. The alternative would be to change the source code and compile, but that was untenable. Then you would set your array elements with ordinary matrix notation but you would need to specify the stride to the solver to work with that: thus yes, it was solving a block, but it is only capable of solving the upper block. So clearly not intended for general submatrix solving: it is meant for using the upper block of a matrix in lieu of dynamically allocating the matrix to the correct size. Alternatively they could have required people to work with 1d arrays and manually handle the matrix indexing, but that would have been unfriendly.
    - gus_massa 5y ago
      And there is the "intersection format" http://fortranwiki.org/fortran/show/Continuation+lines http://fortranwiki.org/fortran/show/Continuation+lines that use a careful placement and combination to make the code legal in the fixed and free format. It's useful when your coworkers have a lot of old code and refuse to modernize it, and you want to at least make the new code nice.
  - silverfrost 5y ago
    and Fortran 77 is compatible with Fortran 66
    - pklausler 5y ago
      Except where it wasn't, of course. F'66 always executes each DO loop at least one iteration, while F'77 introduced zero-trip DO loops.
- TheRealKing 5y ago
  Actually, at least Cray, Intel, and NAG Fortran compilers already fully support Fortran 2018 standard.
  - theodorethomas 5y ago
    NAG Fortran Compiler 7.0 fully supports F2003 and partially supports F2008 and F2018. I should know! https://www.nag.com/content/nag-fortran-compiler https://www.nag.com/content/nag-fortran-compiler
deleted 5y ago
[deleted]

39 points by CTOSian 5y ago

Old content (this is from 1992) should have a year in the title. This is a summary of Fortran 77. The latest standard is Fortran 2018, and Fortran 202x is being worked on. Some features of Fortran 2018 have been implemented in compilers. For current information on Fortran one should visit https://fortran-lang.org/ https://fortran-lang.org/ .

hatmatrix 5y ago
I find it remarkable that modern Fortran implements many advanced features while remaining backward compatible with Fortran 77, which, visually, looks like a different language.
- jabl 5y ago
  Fortran 90 introduced 'free form', a more modern syntax compared to ye olde FORTRAN. Typically free form source code is denoted by a '.f90' extension whereas '.f' is for the old style fixed form.
  - sampo 5y ago
    It is weird that Fortran was modernized 30 years ago, but the old prejudicies live on. Maybe programming languages teachers in CS departments are now telling their students the same jokes "look how primitive FORTRAN is" that their own teachers told them a generation earlier. So the primitive FORTRAN 77 lives on in Computer Science lore, while Fortran 90/95/03/08/13 is what people in the actual number crunching community use. Let's wait until 2050s and see, whatever Fortran 2050 will be like, if CS people will still joke about Fortran as if it was FORTRAN 77.
    - BlackFly 5y ago
      People will joke about the primitiveness of Fortran as long as they are required to preface every module and program with `implicit none`. Also, every time they pick up lapack and need to specify the "leading dimension of A" they will recall how Fortran had it's roots in a language without dynamic memory allocation and how they're still living with that legacy. Fortran's legacy leaks all over the place: you rapidly get a feel that it is something which is old and creaky, even if it is actually old and rock solid. The ergonomics are very much not modern, though, but as with all discussions of ergonomics, that is going to depend on how you like to hold your tool. Not that other languages which have widespread support also have similar historical mistake leakage. Null vs Optional in Java comes to mind. The python 2 -> 3 debacle was a similar sort of "historical mistake correction" but the breakage of backwards compatibility lead to quite some polarization. Actually, in python 2 -> 3, the python core developers tried to fix a historical defect that fortran still has: print as a keyword vs a function.
      - theodorethomas 5y ago
        <as long as they are required to preface every module and program with `implicit none`> A small price to pay for being able to run code from 60 years ago. And no, there is no such requirement as such. <need to specify the "leading dimension of A"> A very clever way of applying your algo to a submatrix from the days of sequence association and no array expressions. Nothing to do with dynamic memory allocation and you know the compiler will have no excuse to copy data. Why is it a defect that I/O needs keyword? Fortran has doubled-down on that "defect" by making coarray references through syntax [] and not an MPI-like procedure call. I don't think it's a defect at all, it's a strength.
        BlackFly 5y ago
        I really don't understand why you're arguing with my explanation. I'm not attacking fortran, I'm explaining why it will feel old to people: because it has things in it that people moved on from. Heck, I'd even agree that it is a sort of bad attitude to automatically discount something because of such legacy. But there are clear historical artifacts in the language (like most languages today). > A very clever way of applying your algo to a submatrix from the days of sequence association and no array expressions. This isn't why you specify the leading dimension, it is just a useful feature of the leftover artifact of the lack of dynamic allocation. If the algorithms were written today, the array slicing notation would simply be used to achieve that. Back in Fortran 66 days, you would compile a large 2d array to solve the biggest problem you wanted to solve because you couldn't dynamically allocate. The alternative would be to change the source code and compile, but that was untenable. Then you would set your array elements with ordinary matrix notation but you would need to specify the stride to the solver to work with that: thus yes, it was solving a block, but it is only capable of solving the upper block. So clearly not intended for general submatrix solving: it is meant for using the upper block of a matrix in lieu of dynamically allocating the matrix to the correct size. Alternatively they could have required people to work with 1d arrays and manually handle the matrix indexing, but that would have been unfriendly.
  - gus_massa 5y ago
    And there is the "intersection format" http://fortranwiki.org/fortran/show/Continuation+lines http://fortranwiki.org/fortran/show/Continuation+lines that use a careful placement and combination to make the code legal in the fixed and free format. It's useful when your coworkers have a lot of old code and refuse to modernize it, and you want to at least make the new code nice.
- silverfrost 5y ago
  and Fortran 77 is compatible with Fortran 66
  - pklausler 5y ago
    Except where it wasn't, of course. F'66 always executes each DO loop at least one iteration, while F'77 introduced zero-trip DO loops.
TheRealKing 5y ago
Actually, at least Cray, Intel, and NAG Fortran compilers already fully support Fortran 2018 standard.
- theodorethomas 5y ago
  NAG Fortran Compiler 7.0 fully supports F2003 and partially supports F2008 and F2018. I should know! https://www.nag.com/content/nag-fortran-compiler https://www.nag.com/content/nag-fortran-compiler

deleted 5y ago

[deleted]