Is there a "standard" file suffix for modern Fortran code?

86

Should gfortran miraculously start to default files with .f suffix to free-form source, then why can’t the person trying to work with BLAS from netlib start to use the following with that library:

gfortran -std=legacy -ffixed-form

87

Changing the defaults is none of the conflicts you describe.

Also the evidence in this thread and countless others is that it is indeed an overwhelming fraction of the programmers who now seek and would very much appreciate the different defaults: and who would gravitate immediately to LFortran when it supports them, I know I would.

  • a file with .f suffix is treated as free-form source by default unless the programmer supplies an option, a la -fixed with Intel, that informs the compiler to treat it as fixed-form source

  • each relevant scope - primarily module, submodule, interface - is treated as if explicit typing is in effect by default, an implicit none thus becomes advisory only a la RECURSIVE starting Fortran 2018 I e., unless a programmer inserts IMPLICIT statement (s) with the desired mapping.

and so forth.

The supposed conflicts are only because any proposal, even to a default setting, is treated as OMG, as though the world was going to end, and a strong undercurrent develops to deflate / stop the proposal, this is highly demotivating for many current programmers and most new programmers.

89

Anyone who grabs such a file shall rename the suffix, say to .for or .ftn, if it has .f as the suffix.

Separately, the Turing award winner has mostly moved on from Fortran. And a lot of new stuff from the work led by this winner appears in other languages with bindings for Fortran in a newer standard revision, generally consumable in free-form source.

Renaming innumerable files is neither difficult nor time-consuming.

And it is not repetitive, look at the leading work by @jacobwilliams with *PACK, one can lead and the others follow.

The arguments against switching the .f suffix to default to free-form are extremely weak and getting weaker.

91

gfortran allows compiling any file. Try

gfortran -x f95 myfile.fortran

This is quite a bit different than the Intel -extfor option, in that it basically says any file is assumed to be a fortran file, and defaults to free-form (which can be overridden with another switch). The most interesting thing to me is the file can be a single dash (“-”) so you can compile standard input. I find that very useful with non-standard pre-processing as you can do things like
call any Fortran filter or custom preprocessor. Each method has pros and cons. I use a custom preprocessor, and this feature allows avoiding the intermediate files which I find to be a great feature.

 prep file.md|gfortran -x f95 -

as one example takes a Markdown file and extracts the lines between “```fortran” and “```” and compiles it with no intermediate files for example.

92

And this task must be done over and over again each time the files are downloaded by a new user. It is not just a one-time source code change. That is the nature of legacy code and legacy de facto standard defaults. This is what must happen with every one of these backward incompatible changes that have been suggested.

2 Likes
93

Here are two references for directives that allow mixed-format files:

Cray

https://support.hpe.com/hpesc/public/docDisplay?docId=a00115296en_us&page=FREE.html

Intel

As you can see, lots of other interesting directives as well. But it takes you down the path of vendor-specific options.

94

I think .fortran is not too bad. Long extensions are not as big a deal nowadays (e.g., .code-workspace.

1 Like
95

That explains the -fI-am-an-idiot flag.

1 Like
96

Of course the real world is often having both fixed- and free-form files. That’s why I have two sets of FFLAGS in such cases. You just write them once, use them everywhere. Who really cares what the filename extension is… it could very well be .foo for all I care. I’m not trying to say the topic is pointless, I am just saying the filename extension is just a convention, and if someone has it rely on it, it has to make sense and not being misleading. f90 is misleading to at least… f90% of new users, pun very much intended. :laughing:

If it were just “some student” we wouldn’t have this thread revived and hot, I guess… Nobody would care.

The message here is this: is there anyone out there who thinks f90 makes sense as an extension that actually means “free-form”? It had a perfect meaning back when it was introduced, since Fortran 90 was the only free-form version of the language. But that was… 30+ years ago. Does it make any sense now, or even when Fortran 2003 was introduced (and it was a major revision as well.)

Fortran 90+ is easy to teach and use. It could be the language of choice, not just for number crunchers but for anyone who wants to learn programming. And yet people are still trying to learn C++ instead, which is objectively way harder to learn, with arguably the same (if not worse) results - performance-wise and otherwise. Or they learn… interpreted languages, even for number crunching. One of the many reasons we see this happening is the persistent obsession to change any convention, even though it’s blatantly outdated. Even a filename extension becomes a big deal…
Admittedly, that’s not the main reason Fortran is not as popular, the “lingua franca” it could be nowadays. The main reason is misinformed people following the trend. But still, refusing to change can be a fatal mistake. And again, nobody said legacy code has to die. It is an invaluable tool afterall, I use it whenever I need to and I am perfectly fine with it. Not to mention it is an indivisible part of the language’s long history. Preserving the past is one thing, being stuck to it is another.

5 Likes
97

That’s not enough. If the file extension does no longer allow differentiating the fixed-form from the free-foorm, then you have to explicitly list all individual source files in your build system (whatever it is) to say “this one is free-form, this one is fixed-form, etc…”.

Let alone all the source editors who rely on the extension for syntax highlighting (which is slightly different between fixed-form and free-form).

From the moment it is a widely accepted convention (and it is), everybody cares actually… in the sense that if you change the convention everybody will be potentially impacted.

Forumers love having such discussions… But forumers are a tiny part of the developers. And even among the forumers here, I can read only a handful of them who regularly talk about things like “implicit typing”, “implied save”, file extensions… What is a handful among a tiny part?

Of course with some cherry picking one can try demonstrating the opposite…

We can all agree, 30 years later, that .f90 was probably not the best possible choice. But is it a big deal ? Definitely not.

I feel some semantic shift here : nobody is “refusing to change”.

Now if you mean “refusing to change the file extensions (or similar stuff)”, then qualifying that as “a fatal mistake” is at best an unsupported assertion, and if you ask me, nothing more than a fantasy.

The reasons why Fortran has lost its momentum have been largely investigated and discussed along the years, and there are infinitely “better” reasons why it happened (and happens) than minor issues like the ones discussed here.

98

@epagone,

Perhaps you will explain to the audience what exactly you meant by “reclaiming .f” file suffix?

@Pap,

And maybe you can elaborate for the readers what you meant when you used the term “reclaim” after @epagone’s post here?

I understood it as following:

  1. Currently there are processors such as gfortran, Intel Fortran, etc. (see @ivanpribec 's table upthread for full list) that presume by default a file with .f suffix is fixed-form source.
  2. Thus with a file such as foo.f, no additional compiler option such as -ffixed-form (or -fixed with Intel Fortran) is needed to process it, the compiler does it automatically.
  3. Whereas an explicit compiler option such as -ffree-form (or -free with Intel Fortran) will be needed if a programmer wanted the file foo.f to be considered as free-form source by the processor.
  4. Whereas the compiler will process the file as free-form source with no additional options needed if the programmer were to name the file as foo.f90.
  5. Whereas a file named as foo.f90 causes certain misunderstanding and wrong impressions at times in the programmer but more importantly among her teams, her management, and the new member of her Community,
  6. Thus there remains a desire to name the file as foo.f whereas the added requirement mentioned in point #3 above demotivates the programmer and her team from using .f as the suffix for free-form source.
  7. Thus you propose that the processor, instead of default to fixed-form source, shall default to free-form source.
  8. With such a change in default, another programmer who works with legacy code in files with suffix .f can continue to do so, however the onus to use a compiler option - as explained in point #3 - is now shifted to this programmer. Or, this programmer can rename the file(s), e.g., bar.f, to bar.for and can continue without any other changes as far as the processor is concerned.
  9. Whereas yet another programmer who already has been working with files in fixed-form source with suffixes such as .for or .ftn, etc. will see no change in their workflow from this proposal.

Do the above points reflect what your proposed change is about? That is, the essence of your proposal is a change in default with .f suffix as mentioned in point #7 above.

99

As discussed already in this thread, the filename determines which FFLAGS… options are invoked by default. With make for example, there is one set of compilation rules for

.f.o:

and another set of compilation rules for

.f90.o:

Also, as others have pointed out, text editors indent and highlight text differently based on the file extension. In this case, since the file extension depends on the source code format (and visa versa), that is not just a tangential feature, it is the entire basis of that text editor feature.

If a new file extension were adopted, say .fort just as an example, then users can add the

.fort.o:

default compilation rule to their Makefiles, and they can define the default mode within their text editor, and all is good. That change would be backwards compatible otherwise, old files with the old (confusing) .f90 extensions would still continue to compile the same way and the editor would still default correctly. But if the new extension is not backwards compatible, say .f is suddenly supposed to change its meaning, then that is more disruptive to the whole system based on these de facto standards.

In the meantime, just tell students and new programmers that .f90 does not mean the source code is restricted to only f90 features; tell them that it is the file extension for free form source code that was first introduced with f90.

100

… or he/she could just set a system compiler variable so that filename convention defaults to legacy, as I already mentioned above. Set it and forget it, if the old convention is desirable for someone. No need to rename files or even change/add any FFLAGS that way.
I work with legacy code as well.

Yes.
I will happily welcome any suffix that’s not misleading though.

1 Like
101

I’m pretty sure everybody does that several times each semester. To be honest, that’s not a big deal, and Fortran tutors have more important issues to deal with. We probably have to discuss those instead of just the filename conventions.
If I had to name one, that’s the lack of a strict pedantic FFLAG. Something that will prevent newcomers from using common blocks and external statements instead of modules, format statements, public modules by default (which lead to “header hell”,) procedure arguments without specified intent, functions with intent(out) arguments, etc. All the stuff that might be ok in the hands of an experienced programmer, but very frustrating and flat-out dangerous for someone who is still learning. I dare say there is a generation of programmers who use an ugly mix of FORTRAN and Fortran in the exact same program entity, simply because the compiler lets them do so by default.

102

Among all the suggestions thus far, .f is in my mind the best suffix for Fortran source code files including with free-form source.

.fortran is the next best, it clearly has a Zen feel to it, “explicit is better than implicit”!

Thank you @art-rasa for suggesting .fortran:.

  • my “implicit bias” from early days on Windows 95 OS toward working with file suffixes with 3 or less characters showed with not being open toward .fortran until now. But on modern systems, a 7-character file suffix that is not at all a big deal.

Nonetheless, I really do believe changing the default of .f file suffix with compilers as free-form source is not as disruptive as some here make it out to be.

But if I am totally wrong and it really is “all hell breaks loose” scenario, it too sounds like a really, really, really, really good disruption for the Fortran ecosystem, a lot of good can come out of it! In a hypothetical scenario where I have all power to make such a change with the press of a button, I would do so in a flash.

So I will continue to clamor for .f as default free-form source. And from now on, I will use .f as the file suffix for any source examples I post online and just as I am essentially forced always to include -standard-semantics with Intel Fortran, I will add -free to the specified compiler options along with the .f file.

But I am going to look at .fortran as file suffix also and may be I will trial it among some teams at work and see how it goes.

Attention @greenrongreen , how difficult it will be for Intel Fortran to include .fortran file suffix as supported for free-form source right “off the shelf” with Intel oneAPI toolkits. a la .f90?

2 Likes
103

Not so. -extfor allows you to specify additional file types (extensions) that are to be treated as Fortran source. You may be thinking of -Tf, which does do what you describe.

104

For what it’s worth, I would prefer to see this level of intensity be directed towards features that Fortran doesn’t currently offer. Aren’t there more useful things to spend ones efforts on?

9 Likes
105

Would it be possible to utilize fpm to test other file suffixes? I don’t think someone will try to compile source files from a fpm project manually, so fpm could use its own convention, e.g. .free and .fix for its source files.
If we could redirect the effort put into this discussion into fpm, we might even teach fpm to automatically detect the source form (optionally enabled in fpm.toml). .f could then represent both “free” and “fixed” or maybe even “flexible”. :sweat_smile:

108

Hi all, thank you for trying to solve this naming problem. I am new to the forum. I also prefer .f for (modern) Fortran. As a second choice I would like to propose .ft that stands for “Formula Translator”, which was the origin of Fortran’s name. Besides .ft carries the two stronger consonants in the Fortran word. What do you think about it ? Best.

1 Like