Yes, please use .f90.
I also feel .fx would be a nice choice (because it includes “f” and is probably unlikely to overlap with existing suffixes). Indeed, more than 10 years ago I used a script to convert my custom Fortran-like code (which I called “extended Fortran”) to the standard one (much like cpp or fypp). The extended Fortran sources had a suffix of .fx (where x means “extended”) and allowed for the use of in-place assignment (like +=), no need to write call, etc. X also seems successfully used for various brand names (like OSX and Space-X).
But one caveat may be that .fx is similar to foreign exchange 
2 Likes
old thread but starting a new fortran project so…I agree that .fx seems like the best option by far…
1 Like
I like this idea.
Almost every single person I talk to (I work in physics) believes Fortran 90/95 is basically the latest standard. They’re surprised when I say there were 2003, 2008 and 2018 standard updates, which introduce a significant amount of features. I wonder if the .f90 extension being the standard is contributing to this idea, as it certainly seems like it on the surface to someone not tuned in to the Fortran community.
I think so. Like an out-dated comment in source code, the “90” in “f90” suggests something specific about this source file (even though, in most cases nowadays, it isn’t). Casual explorers of modern Fortran repositories that are not familiar with the history of the “f90” suffix may very well get the impression that most modern Fortran projects are indeed written in Fortran 90.
2 Likes
Lucky you, I meet more people still thinking FORTRAN 77 is the latest standard. At least thinking that’s Fortran 90 is some kind of progress. Who knows, maybe in another 20 years they 'll discover Fortran 2003. 
But you are right, .f90 is definitely frustrating. How hard is it for someone not knowing much about the language to assume that’s the latest standard?
I still think reclaiming .f is the best way to go. It’s simple and there is no year implying anything. Not to mention .f90 has a potential future terrifying bug. Imagine people being panicked because of the Y2090 “bug”. Not that I care, I won’t see that happening. 
3 Likes
Indeed, there are people who refer to the language itself as “F90” in the same context as C++, etc., in essence synonymously with other language names - see this by @ferrad .
That further exacerbates the situation with the misunderstandings around the language.
Re: reclaiming .f, see this comment by @ivanpribec at the J3 Fortran site, “If fixed-form was removed/deprecated then we, modern free-form Fortran people, could again use the .f file ending, instead of defaulting to .f90 (which we use just out of convenience since it directly works on both the Intel and gfortran compiler, without the need for extra compiler flags).”
However, the problem with Fortran is again and again and again the same: there appears a crucial “underground” faction of “big” and “important” customers - either real or “ghosts” - whose interests the compiler implementors strive to meet or retain first and foremost.
It has thus been a struggle since the early days of the work toward what was then Fortran 8X (that later became Fortran 90) and which continues to this day. This leads to certain proposals or changes facing monumental disagreement and lack of support.
So the aspect with this problem that is of relevance to this thread is the current crop of compiler vendors will refuse to allow either
free-formas the general default for the source they process, or- at least one of
.foror.fto be released from their clutches as being considered as fixed-form by default
Basically in the name of backward compatibility and some “big”/“important” customers, there will be little to no useful support for what is good for the new community of Fortran practitioners, many of whom are not born yet or who are just learning to speak their first words now. The backward thinking is so shameful and unbearable.
The only recourse is certain firm actions by the community:
fpmsystem treats free-form source as the default via suitable options (e.g.,-ffree-formcompiler option withgfortran), then the file extensions become immaterial and the practitioners usingfpmcan move away fromf90toward.for.forwhatever the Community settles on.- Forward-thinking leaders and compilers such as
LFortrantreat free-form as the default and the Community moves toward such processors which then creates significant market pressures for the other processors.
Something has gotta give …
1 Like
Yet another depressing, narrow minded, divisive post, this time about something as trivial as a file name extension.
There is absolutely no need to break any kind of backward compatibility to address this issue. First, there is no mention of filename conventions in the fortran standard, so this whole topic is outside of that discussion (e.g. regarding changing default implicit mapping, etc.). Second, to the extent that a new de facto standard extension is introduced and adopted, all that is necessary is to choose the extension and have the various compilers adopt it. For example, if .fx and .FX are chosen, then compilers can continue to use the old defaults ( .f90, .F90, .f95, .F95, etc) and to treat the new extensions in the same way. For those of us using Makefiles or other build systems, we can configure things to work the same way as before for our legacy files and to incorporate as appropriate the new files. That’s it. That’s all it takes to solve this problem.
3 Likes
Backwards compatibility is one thing, backward thinking is another. Nobody said old code has to die. It has to be preserved, not only because it is still used and it just works (even though people are trying to port it to… C++ instead of modern Fortran.) It has to be preserved because it’s part of the language’s long history as well. But why the hell that means we still have to cope with conventions that are just too outdated?
.f90 is an ugly convention, if you ask me, that can (and does) cause frustration. And it’s not the only one. Just today I had yet another moment of frustration only because I forgot to type implicit none again. And I keep seeing students mixing old FORTRAN with Fortran in the same program, with stuff like external or even format, for Devil’s sake.
We can get rid of such things still preserving legacy code. All it needs is a goddamn flag while compiling legacy code. The default should be not just .f suffix for modern Fortran code, but also something like that being the default compiler behavior, unless specified otherwise. There, problem solved. All those invisible “big players” can still be happy, and newcomers won’t fall into the trap thinking a common block is the perfect way to share data between procedures.
Fortran is the reason terms like “high-level programming language” and “compiler” were invented. It has a long history and yes, it is some kind of a Ship of Theseus. That’s not a bad thing. Lamborghini Countach is also old, it’s the reason the term “supercar” was invented, and guess what, it doesn’t look old at all. Why Fortran has to look old or even worse, behave like being old by default?
3 Likes
Just a few days ago I got really confused when a student asked me if he could use Fortran 20xx features during the exam. Having noticed a big quotation mark in my face, he explained he thought that .f90 files used throughout the semester allowed only F90 standard. So either I did not make things clear enough or maybe he did not noticed. Anyway, I felt really bad. It surely wouldn’t happen if the extension were not year-liked
1 Like
How is a compiler supposed to know if this is a modern free form source file, or a legacy fixed form source file, or something in between (such as a modern fortran code written in fixed form)? How should one modify a Makefile (in order to add the goddamn flag) to distinguish between these possibilities?
There is a straightforward way to move forward beyond this issue that does not break backward compatibility. It is right there for everyone to see, plain as day. It simply involves agreeing and adopting a de facto standard. I cannot believe that it would then be difficult to convince compiler writers to adopt such a convention. It should even be straightforward to incorporate this new default directly into make and other build systems.
If a suitable majority coalesces toward .fx (.FX) or some such extension over .f90, there is no debate and everyone can move on. Such a resolution will be part of what I mean by “Something has gotta give…”.
But if an appreciable number of practitioners do not favor .fx or any such and as mentioned here, they prefer .f or .for as the extension for their free-form source code, then the notion that in the name of backward compatibility and the legacy fixed-form source code, such a practice shall not be supported by default is what is backward and divisive. It’s not my posts that are so, it is those positions on defaults that are at the root of the issue.
I’m simply calling out things as they are, trying to “shoot the messenger” ain’t gonna work with me …
Again, the issue is all about defaults.
Why do the intuitive ways a practitioner might attempt all default to the legacy way of doing things, even 31+ years following the iconic Fortran 90 standard revision?
That is the question.
- What is up with that “1” in column 6 of line 2!?
PRINT *, "Hello " //
1 "World!"
END
- And yet that is what the processors will accept by default!
C:\temp>gfortran p.f -o p.exe
C:\temp>p.exe
Hello World!
C:\temp>ren p.f p.for
C:\temp>gfortran p.for -o p.exe
C:\temp>p.exe
Hello World!
C:\temp>ren p.for p.f90
C:\temp>gfortran p.f90 -o p.exe
p.f90:1:26:
1 | PRINT *, "Hello " //
| 1
Error: Syntax error in expression at (1)
p.f90:2:9:
2 | 1 "World!"
| 1
Error: Invalid character in name at (1)
C:\temp>
1 Like
The last thing needed for this is filename suffix. Assume modern Fortran, therefore free form (among many other things) unless a flag tells the compiler it’s old code. Suffix is irrelevant, so f con be used for modern Fortran just as a convention for clarity. “Big players” will just need to add said goddamn flag, or even set a global variable, say $GFORTRAN_ASSUME_LEGACY_CODE and compile old code in fixed form forever, with whatever suffix they like, without the slightest change in their Makefiles.
That’s exactly what we need to avoid. The “something in between” is what makes newcomers frustrated. It is the reason tutors waste hours to explain students why they should use modules instead of common blocks, interfaces instead of extrenal, etcetera etcetera, again and again for an eternity, just becuse the compiler lets them mix old with new making a mess.
FC=gfortran #or whatever else
FFLAGS=... #default flags, modern Fortran assumed
FFLAGS_LEGACY=... #enter goddamn legacy flag here
$(FC) $(FFLAGS) foo.f ... #Compile modern Fortran code here
$(FC) $(FFLAGS_LEGACY) old_foo.for #Compile legacy code here
# Link object code here
1 Like
The confusion about the file extension is another instance of Fortran being burdened by the weight of its legacy. A legacy, in many cases, filled with the limitations, failures of imagination, and flat out bad decisions of our ancestors. A legacy that we are seemingly stuck with until the end of time. A pile of nonsense shoved in the face of every newcomer to Fortran.
Who on earth thought that .f90 was a good extension for free-form source? Why does the Fortran standard say nothing about file extensions? Why are we still even talking about fixed-form source in 2023? Are we stuck with these things until the end of time?
If my compiler vendor told me that they would stop supporting .f90, .for, etc. 5 years from now and I would have to update all my code, I would do it and move on with my life. These kinds of things happen in the Python ecosystem all the time and people make the changes and move on with their lives. Sure we will grumble about them (especially me) but in the long run it hasn’t seemed to hurt Python. Maybe we can learn something from that.
1 Like
Sorry for reviving this haha but yes I do find it really off putting and bizarre to use and tell people to use f90…
Reasons for .fx well summarised above but avoiding breaking things plus being ‘math like’ by allowing x to stand for ‘any year’ (could stylise as .f$x$ latex style in graphics) appeals to me
One could even set the “rules”:
FC=gfortran #or whatever else
FFLAGS=-ffree-form ... #default flags, modern Fortran assumed
FFLAGS_LEGACY=-ffixed-form ... #enter goddamn legacy flag here
#Compile modern Fortran code here
%.o: %.f
$(FC) $(FFLAGS) -c $< -o $@
#Compile legacy code here
%.o: %.for
$(FC) $(FFLAGS_LEGACY) -c $< -o $@
# Link object code here
thus being able to compile *.f files as free-form Fortran
I understand your argument, I just don’t agree with it. What you are suggesting has already been tried before with the F language. It was a “clean” subset of modern fortran that did not allow many legacy features. It forced programmers to use only new “modern” constructs, and if you wanted to use legacy code, you had to convert it to the supported subset. The F language failed, despite its touted advantages, which of course is exactly what would happen to fortran if the same kinds of restrictions and limitations were imposed on it. There was another similar fortran dialect about the same time, ELF90, and of course it failed too. “Those that fail to learn from history are doomed to repeat it.” --Winston Churchill.
As for the Makefile examples, none of those reflect how programmers actually use make. Typical projects have a mixture of source codes, not only in fixed and free form fortran, but also other languages and even shell scripts. Default compilation rules are defined based on the file extension. So a
.f.o:
rule is different from a
.f90.o:
rule. If you get the wrong rule associated with the wrong source file, the compiler will tell you, just as if you try to compile a fortran code with a pascal compiler. This is a feature, not a bug. It allows the programmer to control the options for the various files, while simplifying the overall process. Specifically, the compilation commands for each individual source file need not be listed. Only the compilation dependencies (which determine the compilation order) and the list of objects that are required to link the program are specified.
None of this has anything to do with “Big players”. All of this applies to single individuals just as it applies to large teams. It is counterproductive to try to divide the fortran programming community in this way.
Moving toward better defaults - free-form source for example - after decades of standard extensions and experience is not even evolutionary, let alone revolutionary.
The analogy with the attempts at F as a Fortran subset or ELF, etc. does not hold at all in this instance.
The only lesson from “history” here, considering where Fortran finds itself in the annals of scientific computing from being the lingua franca to an also ran, will be to stop digging when in a hole, for digging further into the hole is exactly what those refusing to change are causing Fortran.
By the way, Churchill had merely paraphrased Santayana who had reminded, “those who cannot remember the past are condemned to repeat it.” It appears repeatedly from the arguments a fair bit of the past is not being remembered and the mistakes from the 1970s and 1980s with Fortran are being repeated over and over again.
Separately, the failure of imagination when it comes to Makefiles and the build chain toolsets is beyond stunning.
1 Like