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?

[milancurcic]

@awvwgk @epagone

All these other build systems that you discuss--CMake, Meson, autotools--are (mostly) language agnostic.

fpm is language specific. It's exactly what Fortran lacks and needs. Just like Cargo for Rust.

We didn't start with the question how can we make CMake, Meson, or autotools, but better. We started with the question, what is it that Fortran needs? What will make a Fortran programmer happier? With special attention to new Fortran programmers, an endangered and almost extinct species.

Try giving CMake or autotools to somebody new to these tools and watch them pull their hair out for a week straight. Let's face it, unless you dug your way through the mud and became an expert, using them sucks. I can't speak for Meson.

These tools are also not package managers but build systems, as far as I understand them.

So fpm does not aim to replace these tools. It's more orthogonal than competitive with them. Projects that need them will continue using them. You already don't need these tools for most new Fortran projects, and experience is vastly superior IMO.

Sure, designing and building fpm is a lot of fun. But saying we do it just for fun is misleading.

[awvwgk]

Sure, designing and building fpm is a lot of fun. But saying we do it just for fun is misleading.

I should have worded it better:
Because it makes programming Fortran fun.

[milancurcic]

I wrote more on how I see the role of fpm in Understanding intent.

[epagone]

Just two quotes to go back to the pros and cons of the discussion:

@awvwgk wrote:

I certainly don't enjoy writing CMake build files because it requires a lot of boilerplate

@milancurcic wrote:

Try giving CMake or autotools to somebody new to these tools and watch them pull their hair out for a week straight. Let's face it, unless you dug your way through the mud and became an expert, using them sucks.

I totally agree with both and, from my standpoint, this is enough to "take home" the message that if we break direct compatibility with such tools is not a "con": they are already complicated, require time, effort and attention regardless. Plus, if we develop the relevant back-ends, the problem evaporates entirely.

Said that, I realise that I have been imprecise with my my wording and I am sorry if I might have also sounded too provocative (it was not my intention).

[vmagnin]

Try giving CMake or autotools to somebody new to these tools and watch them pull their hair out for a week straight. Let's face it, unless you dug your way through the mud and became an expert, using them sucks. I can't speak for Meson.

My experience is that CMake is very powerful but complicated (and verbose). Meson is more simple to use, with a Python like syntax (fpm seems to be of the same family, and I like that). Although Meson is quickly evolving, it still does not install correctly the .mod Fortran files. I tried migrating gtk-fortran to Meson but I was blocked by that problem. It's multi-language and Fortran is not a priority.

What I like in fpm is that it is totally oriented toward Fortran. It is simple to use, with a clear syntax. It is perfect for launching small projects (probably it will soon be OK for bigger projects). But the fpm killer feature is of course the way it can manage dependencies: already, being able to automatically git clone other fpm projects is awesome. But if it becomes able to do that with CMake or Meson, wow! That's what Fortran needs to cure its scattered ecosystem.

To return to the subject, I have divided opinions about the .f90 problem. I have no experience of compiling old .f files from big libraries. I have always modernized old code written in my team when confronted to Fortran 77 codes (typically a few thousands lines). So I can't say much. Only that I am not sure .f90 is a so important problem. I don't know.

[certik]

Let's discuss CMake elsewhere (especially since we all agree on the pros and cons anyway and are just reformulating the same arguments with different words) and focus just on the .f in this issue.

The fact that Vasp uses .f for free form might be enough of an argument, as Vasp has historically been the single most used code on many HPC clusters based on CPU hours.

My personal preference so far is this:

1. If there is community will, then let's reclaim .f
2. If there is not enough community will, then let's stick to .f90
3. Using .fpm would be my third preference (i.e., I would not bother and just stick to .f90)
4. All other suggestions so far for other extensions

This issue is symbolic, at least for me. It is how Fortran is perceived, and if we managed to reclaim it and keep all the tooling working, I think this could be very exciting for newcomers to the language. And also it would be proof that our community is serious about Fortran and has the manpower (or will) to change things.

However (and I can't stress this enough): doing something like this is only worth it if we are 100% serious about this. It is not worth doing if we are not convinced, as it will only fracture the Fortran ecosystem more.

My recommendation at this point: let's keep using .f90 for now and concentrate on making fpm better. But let's keep thinking about reclaiming .f. It is a thought that needs time. My initial reaction was "not a good idea". But thinking it through, I like it. But as I said, we have to be unanimous about this.

[milancurcic]

@certik The way you phrased the title of this issue is a big question and beyond the scope of fpm. Regarding that question, I agree with your proposal.

But the question can be much simpler in the context of fpm: Should fpm assume free-form or fixed-form for .f files?

Or perhaps the question is: Should fpm even make assumptions based on source file suffix? (I think not)

I think fpm should assume free-form for all Fortran source files, and explicitly instruct the compiler to build fixed-form if specified in fpm.toml or by some other configuration means.

Then you're not doing any kind of reclaiming, or having to convince compiler makers. You're just setting what we think should be a sane default in fpm, and perhaps even make a recommendation about suffix in the fpm guide.

Consider this scenario:

1. fpm assumes free-form for all source files.
2. fpm recommends .f suffix for Fortran source files in the fpm guide.
3. New Fortran projects that use fpm adopt the .f convention.
4. Let other projects be what they want (.f90, .F, .ftn, etc.)

If fpm is succesful in the long run (the Cargo of Fortran), .f adoption will happen naturally and effortlessly.

[ivan-pi]

In some way the problem of free- and fixed-form is really just a problem of language classification.

Given the large strides made in natural language processing (NLP) in the past few decades, I wonder if the classification of a much less complicated man-made programming language can be so difficult.

At least within the fpm ecosystem, and as long as we could build a robust free/fixed-form classifier, free- and fixed-form might be able to co-exist side by side under the same .f extension.

Some cons of this approach:

• we need to build a robust classifier
• it introduces an overhead of fpm having to analyze each file (it could cache the result though)
• potential problems once integration with other build tools (CMake, etc.) is desired
• not sure how to deal with files that require preprocessing

If we would try to pursue the auto-detection path, we have a lot of tagged data sets due to the existing convention of .f and .f90. 😄

Edit: some programming language classification tools as proof of concept

• https://github.com/IBM/programming-language-classifier
• https://github.com/gcrowder/programming-language-classifier
• https://reference.wolfram.com/language/ref/classifier/ProgrammingLanguage.html
• Reyes, J., Ramírez, D., & Paciello, J. (2016, December). Automatic classification of source code archives by programming language: A deep learning approach. In 2016 International Conference on Computational Science and Computational Intelligence (CSCI) (pp. 514-519). IEEE. (download pdf)

[certik]

I thought about auto-detecting free/fixed-form in .f and I think the best is what @milancurcic suggested ---- assume free form for all extensions and if you have a fixed form, you have to specify that manually in fpm.toml. I think this is the way to go.

[ivan-pi]

Down the road this would break most of Fortran syntax highlighting. At least during a short transition period (likely on the order of decades), code editors would become forced to auto-detect or programmers would need to adjust their syntax highlighting settings manually. (For me personally it is not a problem, but for a beginner this might be discouraging.)

Alternatively we would need to convince people to start renaming fixed-form files to .lf as in legacy Fortran or .of for old Fortran.

[sblionel]

You can't reliably auto-detect - it is possible to write code that is correct whether you interpret it as free form or fixed form.

Fixed form is obsolescent. If you want fpm to assume free-form for .f you can, but you'll be going against decades of convention and it is likely to cause more problems than it solves.

[ivan-pi]

You can't reliably auto-detect - it is possible to write code that is correct whether you interpret it as free form or fixed form.

I realize such cases might exist hypothetically. But I don't think they pose a problem. In this special case you can just interpret the file as free-form. If it doesn't compile, then it must be the other form. If it doesn't compile as either, well then something is broken, the code, the compiler, or the standard (in this precise order).

[ivan-pi]

Upon reading some more about programming language classification, the most likely useful feature used to separate between the two forms are comments (C vs !).

Since the language tokens are the same in both free- and fixed-form they cannot be used reliably. Luckily due to historical language features, and differing programming styles, it is likely that the frequency of tokens (including initial whitespace) can still be used for classification.

It would be counter-productive to write your modern Fortran code in an old-fashioned way using computed GOTO's, labelled statements, and other deprecated features, even if theoretically possible. Of course you can do it, even if just for the pleasure of proving a classifier can be wrong sometimes.

[mikolajpp]

I am a newcomer to Fortran, and this issue is something that coincidentally have been on my mind when I first picked up this language some weeks ago.

First, without having a background in the history of fortran, it was confusing to know what extension to pick. I wanted to write "modern fortran", but using the "f18" for the latest standard feels a lot like naming a file after the current year. Then I found out a lot of modern fortran code just uses ".f90" so I stick to that.

Aesthetically it has been disturbing me, since Fortran is the only language I know that does not have unified convention (ok, you might say C++ has cpp, cxx, and cc, but these are of a different nature than Fortran's jungle of versions).

As for a constructive proposal, I myself thought of using ".ff" for all my files (to differentiate it from ".f"), but
reading this whole thread reclaiming the ".f" for modern free form Fortran appeals to me even more.
I found modern fortran to be an appealing language and despite knowing Julia well, I find myself writing more and more code in Fortran.

Taking a pragmatic stand, I would just like to be able to use fpm and plain ".f" files for all my future projects.
Although this might seem harsh, those who disagree with this choice or whose tools are incompatible can just continue using other tools. For users with no emotional stake in Fortran's past having a simple tool with uniform convention is what matter the most.

[urbanjost]

Just to mention some thoughts found in previous discussions about this topic:

• some have proposed that Fortran itself have a directive or option that indicates free or fixed format; which some compilers supply as an option now
• that .fx be a new extension that implies free format, implied implicit none, and no use of certain deprecated features along the lines of the F- project (and as new features appear that has the issue of what is "deprecated" at any particular time; just being a synonym for ".f90" is less problematic)
• and others have suggested a magic string as the first line as in !FORTRAN_FREE.

All would still have issues with the assumptions utilties that supply highlighting might have.

Currently the suffix is totally outside of the standard specifications and is just a (well adapted) convention. Support of .F|.F90 implying preprocessing (and which preprocessor), support of previous "standards" such as .for, .ftn, ... is spotty. Many have argued the standard should state some preference for suffixes when source is in system files, which you have to admit is pretty obviously common. One system allowed for directives in a single file that even allowed sections of C code mixed with fixed and free-format Fortran. I really liked that for building Fortran/C interfaces.

I like the idea of "reclaiming .f" but because there are a number of compilers and tools that would have to change it seems a bit of a challenge without some kind of guidance or feature from the standard itself.

If I were going to try to go down this path I think I would say that .f is preferred but equivalent to .f90 and implies free-format and that fixed-format should use .for or .ftn; (which would already be supported by a number of tools and compilers -- a good number treat .for and .ftn as equivalent to the current behavior with .f).

I use .ff and .FF for essentially all new code, which in my environment implies a specific pre-processor is used, which is not generally applicable but I mention it because I think at some point fpm will have a preprocessor(s) bundled with it and I think .fpm would be a good suffix to reserve for that; and if the preprocessor is also usable as an independent utility that would be easy to use with make and other tools that allow for creating your own suffix rules (my old environment auto-generates make files with a .ff rule but I am moving a lot to fpm slowly - a few M lines to go!).

If there were a suffix rule in fpm that allowed you to call any preprocessor as long as that preprocessor generated a flat .f90 file for distribution as a package (maybe multiple files for multiple passes to generate a MSWindows file and a Linux file and a BSD file and a ...) I would use that; but that would take some fleshing out -- having a "standard" preprocessor would be a lot simpler.

.for seems to be generaly the same as .f, .ftn seems to sometimes be treated like .f and sometimes like .f90; looks like .f77 is supported more than I thought. Updating the fortran Wiki and/or adding a page with recommendations in fortran.lang might be a good place to start. I can see using .f77, and .f90 is widely supported but since I do not see anything enforcing .f03, .f15, .f08, actually mean that it is checked as conforming to a certain standard I think those should be STRONGLY discouraged. If anyone can add to this it would be great:

Many compilers have options to specify assuming fixed or free-format. Some defaults are

Cray:

• .f, .for Fixed-format source, compile
• .F, .FOR Fixed-format source, preprocess, compile
• .f90, .f95, .f03, .f08, .f18, .ftn Free-format source, compile
• .F90, .F95, .F03, .F08, .F18, .FTN Free-format source, preprocess, compile

FREE and FIXED

!DIR$ FREE
!DIR$ FIXED

The FREE and FIXED directives specify whether the source code in the program unit is written in free source form or fixed source form. The FREE and FIXED directives override the -f option, if specified, on the command line.These directives apply to the source file in which they appear, and they allow for switching source forms within a source file.Source form can be changed from within an INCLUDE file. After the INCLUDE file has been processed, the source form reverts back to the source form that was being used prior to processing of the INCLUDE file.

Intel:

   The ifort command interprets input files by their filename suffix as follows:

   * Filenames with the suffix .f90 are interpreted as free-form
     Fortran 95/90 source files.

   * Filenames with the suffix .f, .for, or .ftn are interpreted as
     fixed-form Fortran source files.

   * Filenames  with the suffix .fpp, .F, .FOR, .FTN, or .FPP are
     interpreted as fixed-form Fortran source files, which must
     be preprocessed by the fpp preprocessor before being compiled.

   * Filenames with the suffix .F90 are interpreted as free-form
     Fortran source files, which must be  pre-processed  by  the
     fpp preprocessor before being compiled.

Gfortran:

  Enable preprocessing. The preprocessor is automatically invoked if
  the file extension is .fpp, .FPP,  .F, .FOR, .FTN, .F90, .F95, .F03 or
  .F08. Use this option to manually enable preprocessing of any kind of
  Fortran file.

SEE ALSO

  *  [Fortran Wiki -- file extensions](http://fortranwiki.org/fortran/show/File+extensions)

~

[certik]

I like the idea of "reclaiming .f" but because there are a number of compilers and tools that would have to change it seems a bit of a challenge without some kind of guidance or feature from the standard itself.

I just want to clarify this: compilers do not need to change.

I opened a new issue #366 for a subset of what was discussed here.

[urbanjost]

Since there is no standard for suffixes the compiler support varies extensively. Last I checked the Intel compiler had no switch to change the suffix meaning so .f always means fixed-format; but has very flexible directives such as "!DEC$ FREEFORM and NONFREEFORM that let you change even in the middle of a procedure (which sounds horrible but can be justified when using INCLUDE files). So to use the compiler you would have to copy/link the file to a different filename, for example. So the compiler does not HAVE to change but if it does not compiling a ".f" file as free-format becomes awkward. Every compiler is free to do what it wants. Some can compile from a pipe, some let you define suffixs to search for like ".fixed" and ".free". So no matter what fpm does it is just another convention without some stand taken in the standard.

fpm could always make file copies (my own build system does that primarily to allow for multiple concurrent builds so that is not totally unreasonable) but you cannot depend on the compiler being able to compile a ".f" file as free-format (although it is a common feature - GNU, NVidia, and Cray has such a switch, for example).

[milancurcic]

Last I checked the Intel compiler had no switch to change the suffix meaning so .f always means fixed-format

You don't need that kind of switch. All you need is -free:

$ cat fixed.f 
C     FIXED-FORM PROGRAM
      PRINT *, 'HELLO'
      END
$ ifort fixed.f && ./a.out
 HELLO
$ ifort -free fixed.f 
fixed.f(1): error #5082: Syntax error, found IDENTIFIER 'FIXED' when expecting one of: ( : % [ . = =>
C     FIXED-FORM PROGRAM
------^
compilation aborted for fixed.f (code 1)
$ cat free.f 
! Free-form program
print *, 'hello'
end
$ ifort -free free.f && ./a.out
 hello

[urbanjost]

That was what I meant was missing. Oddly, the man page for ifort I have does not contain the -free switch, but I tried it and it works with the version I have; I started taking a survey because I certainly have used compilers in the past that had no such switch and I remember one in particular that also did not support .F and .F90 implying preprocessing; so far (Cray, GNU, NVidia, now Intel) they have one but they certainly are not required to have it as there is no language standard, just a de-facto standard that has painfully emerged (.fort, .ftn, .for, .f77, ...).

[sblionel]

ifort also has -Tf to tell it that the filename is a Fortran file, if the extension is not one it recognizes. You also need -free if free-form.

I do not believe it is worthwhile spending any effort to change established usage of extensions. If you want fpm to assume that all sources are free-form, go ahead, but I anticipate future complaints when someone tries to package some existing fixed-form code. When I wrote my post in 2013, I thought it was way too late to effect such a change - it's even later now. Spend your time on something new.

[certik]

Here is another interesting case:

symengine/symengine.f90#7

For bigger projects like SymEngine I like to keep the main repository (https://github.com/symengine/symengine) in C++ (in this case) and then have wrappers in other languages as separate repositories with an extension, e.g.:

• https://github.com/symengine/symengine.py
• https://github.com/symengine/symengine.jl
• https://github.com/symengine/symengine.rb
• https://github.com/symengine/symengine.f90
• ...

As you can see, for Fortran I used .f90, because that was the "modern" file extension. In this case we are not talking about a file extension about the name of the project. But the "extension in the project name" is equal to the file extension in every other case (Python, Julia, Ruby, ...), as well as for Fortran, and that's why we chose .f90. However, a lot of people in the Fortran community including @rouson, @milancurcic and many others (myself included) would like to see just using the term Fortran, not adding the 90 in the name. For the name of the project, it makes perfect sense to just call it symengine.f, which is exactly what was proposed in symengine/symengine.f90#7 by a one of the SymEngine maintainers, who is not a Fortran user, but this is what felt natural to him. And I wrote there that I agree that we should do it.

I am posting here to see what others think. It's about 5 months since I opened up the above issue, and I still like to just use .f for Fortran related project names and files.

[everythingfunctional]

This seems like an interesting way to "dip our toe in the water". Any ideas how may users it has? Are they "modern" Fortran users? This would be an interesting experiment to see what chances we have of succeeding in this endeavor.

[everythingfunctional]

FWIW, I'm still in favor of adding -ffree-format (or its equivalent) to the default compiler flags, with an option available in the fpm.toml file to turn it off.

[certik]

Any ideas how may users it has?

SymEngine has quite a few users, including quite a few in the Julia community. The Fortran wrappers I think have exactly zero users because they are not complete yet. Once we make them usable, they will have at least one user: me. :) It's hard to predict how many users they will have, but I think they can potentially have lots of users. With LFortran working down the road, I would like to create tutorials how to do almost anything in Fortran that can be done in Python and Julia. Symbolics is one part of that. Once people can see the potential, I think we will have a lot of users.

[awvwgk]

If we are looking for a project to check this out in practice, I can volunteer some of mine, like toml-f or dftd4, the former is part of the foundation of fpm, while the latter has a decent user base across different projects (like Vasp) and quite a few dependencies itself. Both support fpm, meson and CMake as build systems because they have to integrate with different ecosystems.

So far I only have seen implementations of free format with .f suffix in projects which rely heavily on Makefiles and are purely standalone. Therefore, I'm still not quite convinced that it is worth the trouble to get it working with CMake, but I'd like to get proven wrong on this point and adopt this as best practice for all my Fortran projects.

First step of course would be to implement it in fpm itself.

[LKedward]

FWIW, I'm still in favor of adding -ffree-format (or its equivalent) to the default compiler flags, with an option available in the fpm.toml file to turn it off.

I am also in favour of this proposal.

[certik]

FWIW, I'm still in favor of adding -ffree-format (or its equivalent) to the default compiler flags, with an option available in the fpm.toml file to turn it off.

I am also in favour of this proposal.

Let's do it.

[zaikunzhang]

I support this proposal (reclaiming .f file extension for modern Fortran free form) as strongly as I can.

.f is obviously the ideal extension. Imagine that we are in 2040. What will be the first impression that a normal person gets from .f90? If we believe and hope that Fortran will continue to be actively used 20 years later, the best time to reclaim .f is now.

[awvwgk]

Please checkout #577 (comment) where I described how to add an option for disabling implicit typing in fpm. The same logic can be applied for always using free-form. I think the free-form makes a straight-forward feature for a first contribution to fpm and I'm happy to guide anyone interested through the process of implementing it.

[rouson]

@certik Has this issue been resolved? If so, has the change been implemented?

[certik]

Unfortunately it has not been implemented yet.

[awvwgk]

This has been a low hanging fruit for a while, therefore I didn't pick it to give new contributors a chance to get started with fpm, but I think that is no longer a blocker for me. I implemented part of the required infrastructure in #864, please have a look and let me know if that is what you had in mind.

[rouson]

I might have shot myself in the foot here. My comment yesterday was inspired by a new project that starts with getting some Fortran 77 code to compile and writing a tiny bit of new code plus a unit test for the new code. I now have fpm {build,test,run} working without having to pass any flags and with only a 4-line manifest that just contains boilerplate. The fixed-form .f files are all in app/. The free-form .f90 files are in src/ and test. In other words, it all just works and I don't have to do anything special or jump through any hoops. I'm not sure what's different with my current setup from the issue that I posted yesterday and this will be a challenging week for me to find the time to investigate further, but it makes me wonder whether I should have stayed silent yesterday. :)

[rouson]

I found the crux of issue #863. I have explained the fix in a comment on the issue and closed the issue. Now I will sheepishly admit that it might be nice to preserve the current behavior as the default, but I don't have a really strong opinion on the matter.

[martinmestre]

Hello all. I would be very glad if
.f extension could be used for free format. Is It possible nowadays? If not possible, I would like to suggest another option. How about .ft after the original reason for Fortran: Formula Translator? Best