Reclaiming `.f` file extension for modern Fortran (free form)

[certik]

This was first seriously suggested here:

#359 (comment)

This deserves an issue of its own. Let's discuss the pros and cons, here is a start:

Cons

• Change of established (by now) conventions to use .f for fixed-form and .f90 for free-form (see @sblionel's post for the history of this). Thus creating even more confusion.
• Syntax highlighting in Vim, GitHub, etc. might be incorrect for free-form code in .f files
• Some existing Fortran users might be disappointed with this choice
• While this can be implemented in fpm easily, it might break some other existing tools around Fortran

Pros

• .f is a nice extension, natural for Fortran
• It does not have 90 in the name, thus nothing "old" about it
• Writing fixed-form is not recommended for new projects, so the default good extension should be reserved for free-form, rather than fixed-form
• New Fortran users might like this new extension more

Relevant other issues: #250, #359.

[everythingfunctional]

A comment about the syntax highlighting is that (at least locally), it can be changed without too much effort to still treat .f as free-form Fortran. For every editor I've seen the relationship between a file extension and it's format is an easily customizable mapping. And if this convention catches hold we may start to see the defaults changed as well. A big shift like this has to start somewhere.

[rouson]

@certik because the standard is silent on file extensions, I assume that the goal is to influence compiler developers. Recent compiler support surveys by Chivers and Sleightholme track 10 compilers. That seems like a lot of people to influence and therefore a big effort. I imagine it might face less resistance to propose a new extension that's not widely used. One approach might be for the developer community to add support for the new extension in open-source compilers and then get some projects to adopt to the new extension if those projects only care about compiling with the open-source compilers. That might go a long way toward demonstrating to the vendors that the community wants and supports the idea.

Some suggestions:

• .fsf for "free source form" (which unfortunately could be mistakenly expanded to "fixed source form"),
• .mf for "modern Fortran" (along with other fun, unsavory interpretations),
• .mofo also for "modern Fortran" (and also with fun, unsavory interpretations), and
• .fo which is almost as short and sweet as .f but without the baggage of any suggested so far.

[certik]

@rouson thanks for the comment. This issue is for fpm to simply treat .f files as free-form which we can implement easily, and fpm would then use the appropriate compiler option for all existing commercial and open source compilers. So there is no technical issue from this perspective as far as I can tell, and compilers do not need to change their defaults. It is more of a symbolic issue, but see the other Cons above.

[everythingfunctional]

I'm not sure I'd ever expect the compilers to change their default behavior for .f. They have far too many existing users to support that aren't interested in updating their code or migrating to fpm. But the rest of us can leave those user's behind and influence new tools to make our lives easier. (not that file extension is a burden at all).

But if we wanted to invent a new extension, I might go with .fm - Fortran, modern.

[certik]

@everythingfunctional to reformulate what you said, we are not leaving the users behind, I can easily imagine we would add a simple option to fpm.toml to treat .f as fixed-form for people who prefer that.

[rouson]

Now that I understand the aim better, this proposal makes more sense -- although I'd still suggest choosing something new rather than overloading something well-established. I have a new suggestion: .fpm, which of course indicates that the file is to be built by fpm, which, for the foreseeable future, is the only build system that will recognize whatever new extension is chosen. As a bonus, it can also be interpreted as "Fortran program, modern."

[everythingfunctional]

@certik , yeah, that statement was a bit hyperbolic. We do of course want to have an option to revert back to the old ways, if for know other reason than to make the transition easier for users wishing to adapt older code to use fpm.

I do like @rouson suggestion of .fpm. Not quite as much as .f, but close.

[awvwgk]

After spending a whole day filing bug reports due to new compiler and build systems releases, I'm not sure what gain we are expecting by deviating from existing conventions for file extensions. File extensions outside of the range of f and f90 will most likely introduce breakage down the line with either compilers and/or other build systems, which can become hard to debug once fpm allows to automatically export those build files.

[epagone]

@certik I will consider the cons one by one.

* Change of established (by now) conventions to use `.f` for fixed-form and `.f90` for free-form (see @sblionel's [post](https://stevelionel.com/drfortran/2013/01/11/doctor-fortran-in-source-form-just-wants-to-be-free/) for the history of this). Thus creating even more confusion.

I agree and I like that you correctly mention "by now", i.e. it can be only a transitory confusion ☺️ . I think that this is the only major issue that I personally have. However, if we decide to make this brave move, I think .f minimises the confusion in comparison to any other alternative "new" extension for free form.

* Syntax highlighting in Vim, GitHub, etc. might be incorrect for free-form code in `.f` files

Fair point, but not really a big deal as already explained by @everythingfunctional above in a better way than I could.

* Some existing Fortran users might be disappointed with this choice

I'm not sure that I understand what you mean. I suspect that the real "con" can be understood investigating the cause of such disappointment.

* While this can be implemented in `fpm` easily, it might break some other existing tools around Fortran

I think this is a "pro" 😄 Please let me explain. If I am not wrong, one of the main motivations to start fpm in the first place was to relieve the burden off the shoulders of Fortraneers caused by using messy, hacky or complex solutions to build and distribute their code. For example, cmake is an amazing tool that can even calculate ray tracing but it is definitely not easy to master. In a sense, existing tools, are already "broken" because they require considerable effort to the average Fortran coder. fpm would solve this issue discouraging (mostly newcomers) to adopt other tools that do not support Fortran very well, saving frustration down the line.

I think that @awvwgk's experience in the comment above reinforces some of these points.

[epagone]

However, as the originator of the idea, I would like to point out that my aspiration is broader than "just" reclaiming .f (although at the moment it is the most "visible" proposal): I'd like to remove the legacy ties that make Fortran be recognised as a language stuck in the past, even just with purely cosmetic changes (e.g. what is the big deal in typing "implicit none" here and there?). Please have a look at the first post of the linked issue and feel free to suggest if there is any modern feature that can be "activated" by appropriate flags and that I have not considered.

[awvwgk]

• While this can be implemented in fpm easily, it might break some other existing tools around Fortran

I think this is a "pro" smile Please let me explain. If I am not wrong, one of the main motivations to start fpm in the first place was to relieve the burden off the shoulders of Fortraneers caused by using messy, hacky or complex solutions to build and distribute their code. For example, cmake is an amazing tool that can even calculate ray tracing but it is definitely not easy to master. In a sense, existing tools, are already "broken" because they require considerable effort to the average Fortran coder. fpm would solve this issue discouraging (mostly newcomers) to adopt other tools that do not support Fortran very well, saving frustration down the line.

While I for sure enjoy to deliberately break existing tool chains (usually with benign intentions to improve the overall robustness), it's not something I would put up as a project aim.

There is a worth in build systems like meson and CMake and I wouldn't call them broken for Fortran. Especially meson comes with a powerful project management system which allows to easily reuse code, which is no worse for Fortran than for C++. CMake has its particularities, but those are not aimed against Fortran, they are available for all supported programming languages on equal footing. I certainly don't enjoy writing CMake build files because it requires a lot of boilerplate I get for free in meson, but the resulting build system is solid across platforms and compilers which enables to focus on the important task at hand: writing better software.

---

On the actual topic of reclaiming the f extension for free format source code. There are already huge Fortran projects, like Vasp and Turbomole, that use only f as extension for their Fortran source, which is mostly free format. Obviously there has to be a way to still use fixed format source code in such a huge code base from the past decades. This is usually done manually in a huge Makefile.

For new projects this is less of a problem, so adopting f as default extension would work, with the minor annoyance of having to get the free-format argument right for every supported compiler.

[epagone]

While I for sure enjoy to deliberately break existing tool chains (usually with benign intentions to improve the overall robustness), it's not something I would put up as a project aim.

There is a worth in build systems like meson and CMake and I wouldn't call them broken for Fortran. Especially meson comes with a powerful project management system which allows to easily reuse code, which is no worse for Fortran than for C++. CMake has its particularities, but those are not aimed against Fortran, they are available for all supported programming languages on equal footing. I certainly don't enjoy writing CMake build files because it requires a lot of boilerplate I get for free in meson, but the resulting build system is solid across platforms and compilers which enables to focus on the important task at hand: writing better software.

I think that we are saying the same exact thing (maybe from a different point of view): CMake and meson work really well (but also Autotools, once everything has been set up properly, ok except it's not cross platform, but I hope you'll get the point in a second). The problem is exactly writing all the necessary boilerplate that does not let you focus on writing better software.

If we had already a valid, good all-around Fortran build system, why on Earth are we going the long way to build fpm from scratch?

BTW, thanks for the examples and the links: I was not aware of Vasp and Turbomole. It gives me a lot of hope!

[awvwgk]

If we had already a valid, good all-around Fortran build system, why on Earth are we going the long way to build fpm from scratch?

Because it's fun.

Why would somebody take on the effort to write meson in the first place when there was CMake and autotools around? The Gnome project now moved completely from autotools to meson, so maybe meson was a good idea and offered something you wouldn't get in autotools. If you look at meson you will notice it can do so much less than CMake, meson is not turing complete like CMake, there is no real reason to use meson, except that meson build files require a fraction of the lines you would write for the equivalent CMake project while you still can do 90% of your usual tasks with ease.

So what's up with fpm? Why would we choose a configuration file format like TOML as input over a powerful DSL like offered by meson? If you need the DSL of meson to express non-trivial dependencies in your project, fpm will hardly ever become a real alternative, but if you want to prototype, you can get away with a single line in your fpm.toml input and start immediately.

There is a gap fpm can fill for Fortran, it won't replace CMake or meson, at least in my opinion, but maybe it will allow us to seamlessly integrate with existing CMake and meson projects instead of fracturing the Fortran community with yet another build system (remember FoBiS, foray, ...?).

[epagone]

There is a gap fpm can fill for Fortran, it won't replace CMake or meson, at least in my opinion, but maybe it will allow us to seamlessly integrate with existing CMake and meson projects instead of fracturing the Fortran community with yet another build system (remember FoBiS, foray, ...?).

The fpm interface to CMake or meson is still entirely to be written and mostly to be designed, AFAIK. I can't remotely see why there is a risk of "fracturing the Fortran community" if fpm assumes by default that .f is free from and then the back-end converts appropriately this to CMake, for example (heck, it's just a matter of adding a compiler flag in CMakeLists.txt).

I really do not understand so much concern. Am I missing something?