Re: Converting fixed-to-free format

Michael Prager wrote:
Joe Krahn <jkrahn@xxxxxxxxx> wrote:


It sounds like you are saying Fortran is only alive now to keep all that archaic code useful. If that's all Fortran is to you, then it's already dead.


Look, Fortran is not used mainly to write word processors, or
silly games, or other programs with limited lifespan. It is
used for mathematical and engineering calculations. Those
programs and routines become "archaic" far slower one might
imagine. I am no fan of fixed format, and I'm an enthusiastic
user of F9x5, but I see no value added in REQUIRING periodic
revision of functioning code to get it working with the latest
standard. Quite the opposite: fiddling with working and proven
code just introduces errors.



I agree totally that math routines don't really become obsolete. My point is that it is useful to plan for Fortran's future without worrying about syntax compatibility of the oldest code and newest code in the same source file, even though it is important to keep them functionally compatible.

I have the impression that many suggestions for new Fortran features have been held back due to concerns about old code. It seems to me that an easy solution to keep old code valid without holding back development of new features would be to keep new constructs separate from old ones, especially in the context of a large number of non-standard extensions in older code.

It seems that a straightforward way to distinguish old and new code is fixed-form versus free-form. My intent behind the idea of a general-purpose, high-quality fixed-to-free filter was to keep all of the old code valid, without having to rewrite it. In fact, my intent was that it could reduce the need to rewrite code, because it could deal with the many non-standard extensions. It seems like a lot less effort to have one common fixed-form filter, used as a preprocessor, rather than have multiple compiler vendors trying to implement F2003 while each maintaining their own slightly-incompatible fixed-form parsers.

One big mistake I may have made is the assumption that fixed-format programmers are only working with 'old' code, and that some people would like to keep using fixed format, even while using F2003 features.

In fact, fixed format is not that bad with a good fixed-format-aware editor (sort of like the Python indentation arguments.) The only serious archaic feature of fixed-format is the space insensitivity, where "DO I=1" is the same as "DOI=1", which is why there's an optional comma after DO.

So, maybe instead of a fixed-to-free converter, I should have proposed a fixed-format standardizer, which standardizes code to ensure that all keywords and names always have spaces between words and not within words, which sometimes are program bugs anyhow.

Joe
.

Relevant Pages

  • Re: Where are spaces required in COBOL source code?
    ... >> Please note that the first language I learned was FORTRAN using ... >> fixed-form (punched card) format. ...
    (comp.lang.cobol)
  • Re: Converting fixed-to-free format
    ... archaic code useful. ... If that's all Fortran is to you, ... No. I'm saying that if it changes so that it's no longer backward ... some similar features, but BASIC also has similar features and is not ...
    (comp.lang.fortran)