Proposal: add an option to select fixed-form, make free-form the default

[certik]

Proposal:

1. Make fpm treat all Fortran file extensions (.f, .f90, ...) as free-form by default. fpm is responsible for calling each compiler properly with the correct options (so it would tell each compiler to treat it as free-form). Compilers do not need to change at all.

2. fpm will have an option to turn fixed-form for legacy packages (both on per project or per file basis), such as https://github.com/ivan-pi/LINPACK

Note: compilers do not need to change. This proposal is strictly what fpm does by default.

This proposal will allow people who want to

• continue using .f for fixed-form to do so (with a simple option in `fpm.toml)
• continue using .f90 for free-form to do so (by default)
• start using .f for free-form to do so (by default)

This proposal is not about what fpm new does, that would be a separate issue.

Another way to look at this is that we need an option to select free-form / fixed-form anyway (see #367). The only question is what should be the default. Because we do not recommend to use fixed-form for new projects, the free-form should be the default, and fixed-form should be selected by an option.

Note: this issue can be split into two parts:

a) how to select fixed-form and free-form, the syntax and mechanics of it: #367
b) what should be the project level default (this issue)

[awvwgk]

I would suggest to add a source entry to the build table (or top-level), there we can decide to add file extensions for all three four supported languages in fpm (Fortran, C, C++ and of course legacy Fortran).

[build.source]
fortran = ["f", "f90"]
fortran-legacy = ["ftn", "for"]
c = ["c"]
cpp = ["cpp", "cc"]

This should provide the overall most flexible design, we only have to decide on reasonable defaults.

[milancurcic]

Doing it by file suffix introduces yet another (customizable) convention, just like compilers did.

An alternative is to completely divorce the legacy-modern / fixed-free forms from the source file suffix.

• Assume free format for all source files
• Allow customizing which suffixes denote source files. For example, default list for Fortran could be ['f', 'f90', 'f03', 'f08', 'f18', 'ftn'], but the user should be able to add, e.g. 'ff' to the list if they wish so
• Have a project wide legacy = true switch in the manifest to assume fixed-format for all source files
• Have a per-source file specific legacy = true switch in the manifest to assume fixed-format only for some files.

[awvwgk]

An alternative is to completely divorce the legacy-modern / fixed-free forms from the source file suffix.

I really, really like the idea. Still I'm a bit torn, because I'm using a mixed format project as starting point for my teaching next month. The fixed format part is a redistributed version of the dspev solver from LAPACK and the students never interact directly with this file... yet I would have to create a local subproject for just one file here, which does not look particular elegant.

Edit: Probably could just convert the fixed format to free in this case...

[certik]

@awvwgk your use case is precisely what I had in mind. I think we should allow per file setting also. In other words, perhaps let's do per extension and per file and per project.

[urbanjost]

I agree with the goals and desired behaviors but having gone through this with many suffixes and compilers you want to pick two suffixes.

And even to support .f as a free-format suffix fpm will have to copy the source file to .f90 for some commonly used compilers.

So short of only supporting certain compilers pick two suffixes -- .f and .ftn or .f90 and .f and do not support any others unless it actually means something else like to preprocess it.

Even if I start with a bunch of legacy code that ends in .for or .ftn It takes one ULS command (rename .old .new *.old) to "convert" to any new two-suffix system; so that is not asking much for users to get rid of .f03 and .f08 and such. We tried for a while to use such suffixes to actually connote specific standard conformance but in the long run it was a bad idea. Pick two.

[milancurcic]

I think there's merit to restricting suffixes, as a more "aggressive" way to promote a convention. But I don't see a need for two suffixes, only one: .f. Compilers can be told to compile it in free or fixed form.

[urbanjost]

Seems to have gonequiet, but since I read though over a dozen compiler manuals here is my last vote on the issue:

After taking a survey of major compilers looking at supported suffixes that do not contain dates ".for" comes close for fixed-format but PGI in particular seems to basically only support .f and .f90; but I would hate to have to specify which file is which in the toml file so location rather than suffix seems the easiest to me.

Assume everything is free-format and ends in ".f" or ".F" unless placed in a subdirectory like fixed/ or f77/ under app/, test/, example/, and src/. Since "fixed" is an English word that might be used for other purposes f77/ might be a better choice. It still would be nice if the Standard supplied guidance, and if vendors allowed lists like "-free .f,.f90,.for,.ftn".

As an aside, I did not know GNU allowed "-x mysuffix source.mysuffix" until surveying what was available.. IBM and Intel and GNU all allow for custom suffixes, but it is not clear to me if the options can be specified multiple times.

So not my first choice, but looking at the different compilers and wondering what to do about ".cuf" and noting that the only thing "standardized" is ".f". and ".f90" (if supported, the meanings of .f77, .for, .ftn, .ff vary. For the compilers that allow the post-f90 standard-year suffixes like .f03, .f08, ... at least all those assume free format, as expected ) I would say everything by default should be assumed free-format and should end in "{.F,.f}". "if not now, when?".

All the compilers I looked at had some way of saying the file was free-format or fixed-format regardless of the suffix with a compiler keyword so that is supportable.

Whether a change is made or not the standard, fortran-lang, and fpm should strongly encourage just the use of {.F, .F90, .f, .f90} except for vendor-specific extensions like .CUF.. So if everything was ".f" or ".F" (as @milancurcic suggested) but I could move the file into a subdirectory called deprecated/ or fixed/ (I want to be able to change it with a move, not be editing a config file) I would be good with that. If in the "deprecated" directory .f meant fixed and .f90 meant free I would not mind if the deprecated/ directory was the only place computed GOTO and source without implicit interfaces were allowed either, but maybe that is too draconian.

Note a good number of vendors allow for a pragma-like comment in the source files but it varies from vendor to vendor even when implemented. If that had been done in the standard when free-format was introduced in Fortran90 like

module, free ...::
subroutine,free:: name(...
function,free:: name(...
program,free:: name

and then encouraged the use of one suffix (".f|.F") I would have been happier about it. Until an explicit free or fixed specification was encountered you would have to have a default which for upward-compatibility probably would have been "fixed" which would mean that now-a days everyone would be complaining about having to specify "free" just like is heard about "implicit none" but it would have been better than the current state in my opinion.

Then there are all tweaks to make for other programs like make(1) and editor syntax highlighting and ...

I guess this was such a big change a file suffix was the easiest way to distinguish them, but C did not end up with ".c89" and such; although I dimly do seem to remember using that for some C compiler once upon a time. Of course the battle over suffixes greater than three characters still seems to be ongoing (eg. ".htm" versus ".html") in some quarters.

[epagone]

Assume everything is free-format and ends in ".f" or ".F" unless placed in a subdirectory like fixed/ or f77/ under app/, test/, example/, and src/. Since "fixed" is an English word that might be used for other purposes f77/ might be a better choice. It still would be nice if the Standard supplied guidance, and if vendors allowed lists like "-free .f,.f90,.for,.ftn".

Why not legacy/ instead of fixed/? The latter is more specific but I think the former explains better the rationale behind the potential new default of fpm.

So not my first choice, but looking at the different compilers and wondering what to do about ".cuf" and noting that the only thing "standardized" is ".f". and ".f90" (if supported, the meanings of .f77, .for, .ftn, .ff vary. For the compilers that allow the post-f90 standard-year suffixes like .f03, .f08, ... at least all those assume free format, as expected ) I would say everything by default should be assumed free-format and should end in "{.F,.f}". "if not now, when?".

I entirely agree.

Whether a change is made or not the standard, fortran-lang, and fpm should strongly encourage just the use of {.F, .F90, .f, .f90} except for vendor-specific extensions like .CUF.. So if everything was ".f" or ".F" (as @milancurcic suggested) but I could move the file into a subdirectory called deprecated/ or fixed/ (I want to be able to change it with a move, not be editing a config file) I would be good with that. If in the "deprecated" directory .f meant fixed and .f90 meant free I would not mind if the deprecated/ directory was the only place computed GOTO and source without implicit interfaces were allowed either, but maybe that is too draconian.

This is what I have proposed in the "originator" issue. Let's discuss the suitability of such "draconian" rules there. Maybe we can find a way to make everyone happy without pushing it too much.

[ivan-pi]

Why not legacy/ instead of fixed/? The latter is more specific but I think the former explains better the rationale behind the potential new default of fpm.

According to the article "Defining Legacy Code" there is no clear consensus among developers what legacy means. Even the reference LAPACK continues to be written in an old style of Fortran but is in widespread use (or at least the vendor versions are).

There is also the opinion of Bjarne Stroustrup (creator of C++):

"Legacy code" often differs from its suggested alternative by actually working and scaling.

---

Interestingly, in MFE I could not find any paragraph about conventions with file extensions (presumably, because they are not stated by the standard).

The book by Chirila & Lohmann contains the footnote:

Files containing modern Fortran source code usually have the extension .f90, but the reader may also encounter extensions .f77, .f, or .for, which correspond to older standards; likewise, some developers may use the extensions .f95, .f03, or .f08, to highlight use of features present in the latest revisions of the language—but this practice is discouraged by some authors (e.g. Lionel [2]). To avoid problems, filenames should also not contain whitespace.

Milan's new book also recommends sticking to .f90 for consistency.

What I am trying to point out, is that newcomers to the language might be confused by any default fpm conventions, which differ from written resources, what they learn at university, web-pages, etc.

[ivan-pi]

Whether a change is made or not the standard, fortran-lang, and fpm should strongly encourage just the use of {.F, .F90, .f, .f90} except for vendor-specific extensions like .CUF.. So if everything was ".f" or ".F" (as @milancurcic suggested) but I could move the file into a subdirectory called deprecated/ or fixed/ (I want to be able to change it with a move, not be editing a config file) I would be good with that. If in the "deprecated" directory .f meant fixed and .f90 meant free I would not mind if the deprecated/ directory was the only place computed GOTO and source without implicit interfaces were allowed either, but maybe that is too draconian.

This is what I have proposed in the "originator" issue. Let's discuss the suitability of such "draconian" rules there. Maybe we can find a way to make everyone happy without pushing it too much.

I don't like the idea of a deprecated/ folder tied to language features. For example the Fortran 2018 standard made the forall statetement obsolescent. Would "good programming practice" dictate I should move all my free-form F95+ programs containing the forall construct into a different folder? I don't think so.

[ivan-pi]

After taking a survey of major compilers looking at supported suffixes that do not contain dates ".for" comes close for fixed-format but PGI in particular seems to basically only support .f and .f90; but I would hate to have to specify which file is which in the toml file so location rather than suffix seems the easiest to me.

I tried to summarize the existing defaults for file extensions and the fixed-/free- compiler flags in issue #250. Please feel free to add any I might have missed.

[epagone]

@ivan-pi wrote:

What I am trying to point out, is that newcomers to the language might be confused by any default fpm conventions, which differ from written resources, what they learn at university, web-pages, etc.

I agree that there is the risk of an initial confusion, I've already mentioned this elsewhere. However, I'd bet most of the books and written resources (except rare examples like fortran-lang.org) have no reference to fpm or stdlib. As a rethorical question: should we then scrap fpm and stdlib too? Obviously not.

[milancurcic]

Yes, this discussion is meaningful only in the context of fpm.

So pointing to recommendations that are not fpm-aware, or prior to fpm, while useful to be aware of, are not relevant because they simply reiterate what major compilers use as default.

Recall that this is not about trying to change the culture or conventions head on. This is about asking, "if we are not tied to any past convention, what is the most sensible default for fpm?". Whatever the answer is, use that for fpm, make fpm ubiquitous in the Fortran library ecosystem (it will take years, but it's feasible), and let users decide for themselves what suffix to use.

Fpm will eventually be no less significant tool than any major compiler.

[epagone]

@ivan-pi

I don't like the idea of a deprecated/ folder tied to language features. For example the Fortran 2018 standard made the forall statetement obsolescent. Would "good programming practice" dictate I should move all my free-form F95+ programs containing the forall construct into a different folder? I don't think so.

I respect your opinion. I beg to differ: phasing out obsolescent features it's a healthy practice as long as it is managed not too abruptly, but we need to move on. IMO, exactly the fear of a too hasty language modernisation made Fortran adoption, usage and fields of application continuously shrink in the past couple of decades.

More specifically, I don't believe that we have to align to the standard specifications 100%. If, for example, forall is voted by the community as a useful modern default feature, we can keep it.

[ivan-pi]

@epagone,

I should clarify, I am not necessarily against a folder with implicit fixed-form flag. In fact, I also adopt this type of convention when packaging legacy codes, e.g. https://github.com/ivan-pi/y12m/tree/main/src. But I am against mixing what is the fixed-/free- form issue, with the issue of deprecated and deleted language features.

While I can relate strongly to your sentiment, about Fortran needing to move on (in 2017 my professors where still teaching in a basic F90 style with external subroutines and no modules), I maintain a skeptical attitude towards an alleged drop in Fortran adoption and usage.

While Fortran might not be in the limelight anymore as a general purpose computing language, it still maintains high presence at most HPC centers. The fact the field of applications shrunk is not necessarily a bad thing, simply meaning that other programming languages (some of them influenced by Fortran) which were more suitable for those tasks appeared. From 1960 until 2020 the world population grew from 3 billion to 7.8 billion, and so did the computer penetration among all societal units (households, government organizations, companies, etc.). I find it hard to believe the total number of Fortran programmers would have gone down in the same period, even if the rate of growth might have decreased. I would echo @certik's words in a thread at Discourse:

Fortran has not realized its full potential. If we can realize Fortran’s full potential, I think it will be a better language for scientific computing than Python.

[epagone]

I think this branch of the discussion is definitely OT here (I should have replied in the other issue but, in a hurry, I was carried away, apologies). Anyway, I only partially agree with what you said but I am not in the position to provide a meaningful answer now because it touches several broader topics. A "face to face" conversation might be more effective and, if tomorrow there is time, it would be a good opportunity. I will stop here because we are OT.

[ivan-pi]

My apologies for getting carried away and derailing the thread too. I will join the call tomorrow. 👍