@rwmsu ,
Certain compilers unfortunately will claim a “landgrab” on .for (.FOR) also!
Can you come up with an eminent domain clause to release the “property” from their clutches?!!!
Intel Fortran treats .FOR and .FTN as fixed-form. .FOR was what DEC Fortran used for fixed form on VMS.
I had thought of .ffr for Fortran free-form. As noted in this thread, and in my blog post, the standard is utterly silent on just how source lines are delivered to the processor, so there’s no leverage there. I am supremely skeptical that a single open-source compiler, especially one not in current use, could drive a change here. Just think of the nightmare that is .f03, .f08, etc.
I do like the idea of a standard directive.
This is a nice table that was posted earlier in this thread. For some reason, I thought .fort was used by some compilers, but it isn’t in this list. That is 4 characters, but it appears to be available for the free form source code suffix.
One other aspect of this might need some discussion. Some file systems are case preserving but case insensitive. This means that file.F is distinct from file.f, and the compiler can then treat them differently, but you cannot have both files in the same directory.
The more such discussion takes place online, the more it appears attractive to do as the OP @Pap and also @epagone et al. suggest which is to reclaim .f (and .F) for free-form source.
For one can sit somewhere and contemplate many a permutation and combination, .ffr, .frf, .ffs, .free, .fort, .fart, .fortran, and on and on
But these options only make the case that …
… anyone with fixed-form source in a file with suffix .f better learn to apply an option -fixed or -ffixed-form …
… or rename their file with .for suffix …
… or port the code to free-form, there are tools for that, and these can be further improved also.
… or things better break for you otherwise.
Was wondering the same thing. Some compilers like Cray have supported directives for years
that let you switch between free and fixed format, by the way. With a preprocessor you have to
split the code into multiple files or auto-convert the fixed format to free format.
I kept my code in HTML files for years with the code in XMP sections. HTML Comments allowed specifying file-specific compiler options. When routines were generally separate files it was easy to must make the fixed and free format code go into separate files unless the compiler (like the Cray compiler) supported mixed-format. With the introduction of modules it became much more complicated to maintain a single module with fixed and free-format in it, as you have to convert everything to one format for the compilers that do not allow for mixed format.
XMP became a deprecated HTML feature, so I switched to markdown now. Most markdown dialects already have things like “```fortran” for indicating a Fortran code section. With HTML and markdown it is also easy to keep related C and Fortran in the same file, converters like pandoc(1) let you convert it to a lot of printable formats; and it works great with github, which already converts markdown to HTML; so your code is autmatically nicely formatted text and color-highlighted code.
My Fortran code is run through the prep(1) preprocessor, and then run through cpp/fpp if any remaining line starts with “#”. Sounds complicated, is really quite simple. Do not except others to adapt that as a method but it did make me think that if the preprocessor becomes standardized it SHOULD suggest a new file suffix unless it is strictly only going to be a cpp look-alike.
If it is going to make its own features all the things you mentioned plus things like block comments, multi-language contents (FORTRAN, Fortran, C, …) are all possible. Defintely worth thinking about whether a standard preprocessor should have its own suffix and what it should be at a minimum.
If the people who proposed .f90 (in light of existing .f etc) had offered .fort or .fortran instead I don’t think this discussion would exist…for this and other reasons I think .fortran is pretty solid (or .fort or .fx but for the latter I take the point re it being in use. For the former it might be too close to .for and cause confusion).
The typing of extra characters seems like a non issue to me — who’s creating new files so rapidly that an extra four or so characters matters?
Could a compiler like LFortran just start offering .fortran as an allowable file extension? And someone make a simple tool to convert .fortran to .f90 if other compilers are needed?
I see that “.fn” extension [Fortran] is yet not used by any of the mentioned compilers, so there is a possibility.
1 Like
If it’s not possible to reclaim .f, the rather verbose .fortran doesn’t sound bad to me. Fortran’s is verbose compared to other languages anyway, and that’s not a bad thing either. There was (and it’s probably still there) a paragraph in Mathematica manuals explaining why they opted for verbose syntax and why they will continue to do so.
As @milancurcic said already, a new compiler such as LFortran could establish such a convention and hopefully eventually lead to a new de facto standard.
One thing is sure, .f90 was making sense for the time, but it was short-sighted. It didn’t take long until I started to see .f95, opening the way to suffix hell, like .f03, .f08, etc. Nowadays .f90 is just yet another frustrating relic, which I’m using very reluctantly.
In the past, we also had suggestions like .fff (free form Fortran) and .mf (modern Fortran).
Sorry for making the list even longer. 
(Implicit typing and backwards compatibility - #25 by Carltoffel)
I don’t believe the standard will suggest anything about file suffixes. (I’m not really of the opinion it should). The consequence is that any standards conforming Fortran code could have preprocessor directives, and should be preprocessed, regardless of file extension. The unfortunate consequence is that many existing codes with preprocessor directives may break, because they do not conform to the standard. This suggests to me that it really will be important for the standardized preprocessor to include directives to signal minimum standard version and source format. At that point file suffix will matter only for legacy code, and all the compilers will almost certainly have to settle on a new suffix.
1 Like
For this new project you’re starting in Fortran (great news, kudos), is it possible for you to select the compiler options with various processors you intend to use for this project? Meaning, can you configure the build toolchain such that it can be adapted for your needs?
Please see this.
Can you use something like a compiler option -extfor in your project?
C:\temp>type p.fortran
print *, "Hello World!"
end
C:\temp>ifort /free /standard-semantics /extfor:fortran p.fortran
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.8.0 Build 20221119_000000
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.
Microsoft (R) Incremental Linker Version 14.34.31937.0
Copyright (C) Microsoft Corporation. All rights reserved.
-out:p.exe
-subsystem:console
p.obj
C:\temp>p.exe
Hello World!
C:\temp>
Without the extfor option:
C:\temp>ifort /c /free /standard-semantics p.fortran
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.8.0 Build 20221119_000000
Copyright (C) 1985-2022 Intel Corporation. All rights reserved.
ifort: command line warning #10161: unrecognized source type 'p.fortran'; object file assumed
ifort: warning #10145: no action performed for file 'p.fortran'
On the contrary, the file extension is a logical way to infer how the code is formatted in the file. At least as soon as, and as long as, both fixed-form and free-form files cohabit. The real world in practice is not “having only old fixed-form files and just having to set a damn flag” or “having only modern free-form files” : the real world is very often having both of them, and the file extension is a very convenient way to manage this situation.
By the way, always talking about “Big Players” as if they were a kind of evil (similar to “Big Pharma” or whatever) is… I don’t know… I do not work for a so-called “Big Player”, and still we have a very significant amount of legacy fixed-form files among the thousands of sources files we manage (free-form Fortran, C, C++…).
So what is the message here? “Please change everything in your projects, because recently some student didn’t get that F2018 features could be used in .f90 files”?
+1000…
1 Like
I was unaware that any compiler allowed the source code form to change within a file with directives. Apparently the Cray compiler does this. How flexible is this?
Does it allow subprogram by subprogram to change within a file?
Does it allow a contains procedure to be different from its host procedure?
Does it allow arbitrary blocks of lines within a subprogram to toggle back and forth?
For those who have used this feature, are there any problems that you encounter that might not be obvious?
For the compiler writers, would this feature present compilation problems? I can see how it might if the code parsers for the two forms are not tightly coupled.
Things like file extensions are generally pretty easy to adapt within a build system. Many of my legacy Makefiles have something like
MOD=mod
after which a module file might be referenced as
filename.$(MOD)
The reason for this was that some compilers used lower case .mod as the file extension and others used mixed or upper case. That was shortlived, and eventually everyone started using lower case, or at least had compiler options that allowed that. My newer Makefiles typically just hardwire in the .mod extension (in lower case) where necessary.
The same thing could be done for fortran source file extensions if necessary. Since the de facto conventions (.f/.F and .f90/.F90) have been used for such a long time, it might be tedious to go through and change a large number of Makefiles within a project, but it would be possible. And if the new suffix is backward compatible, the changes need not be done all at once, it could be done as part of whatever routine code maintenance is required over time.
Most of my Makefile dependencies are keyed on the *.o files, not on the *.mod, *.f, or *.f90 file names. I expect other build systems allow the same kind of target/dependency relations to be specified. Many of my Makefiles do not even reference the fortran file extension, the .f.o: association is done with just implicit rules. That is, it is either a built-in default association by the make utiility, or it is specified once and then propagated to the other Makefiles with include directives. So if a build system is configured this way, any file suffix change or addition might occur in just a single place.
Steve, I totally understand your skepticism about this. It’s also helpful for LFortran because it helps identify one of the things that we need to improve–establishing a solid user base. I have no doubt that LFortran will get there eventually, it’s a matter of time. Once LFortran can compile all standard Fortran and builds performant code, being open source will make it a no-brainer for most users. At that point (or even sooner), we can set a recommended convention for explicit typing (LFortran already does this), source file suffix, default source form, etc. It’s essential that the defaults are thoughtful and deliberate (explicit typing, assume free form, compile only e.g. .f or .fortran), but also that it provides compiler options to override the defaults. Most (but not all, and that’s okay) current users should be happy with the default settings, and these sane defaults should be the first thing that newcomers to the language experience. Once ubiquitous, a mature open-source compiler has an opportunity to shape and perhaps even redefine the Fortran eXperience (FX, in analogy to UX) for newcomers to the language. I believe that together with the Fortran Standard Committees and the growing Fortran-lang ecosystem, LFortran can help build and nurture a great Fortran eXperience for the next generation of programmers.
3 Likes
Unless I’m mistaken, certain compilers currently may not accept suffixes other than those that belong to some arbitrary list.
Current gfortran, for example, may not work with .fortran suffix.
Whereas Intel Fortran compilers will only process the file if the -extfor compiler option is included.
To reiterate my broken record, the struggle in certain domains of practitioners - at least one I’m familiar with - has do with all the defaults that come into play with the ecosystem. For example,
- with this thread, it has to do with why in year 2023 must a processor continue to default to fixed-form source for anything, let alone with the top 3 obvious suffixes for Fortran source files -
.f..for, and.ftn. Why can’t at least one of these be released in terms of defaults for the practitioners who have long moved away entirely, for decades now, from fixed-form source. - with the other “painful” threads that arise online around the landmines for practitioners due to omitted
implicit none, why must Fortran, after nearly 50 years ofimplicit nonerecognition, default toimplicit mapping?
It makes no sense. Backward compatibility argument is entirely worn out now. And it is inconsisent.
As I have oft mentioned Fortran 2023 breaks a Fortran 2018 conforming codebase used by a team I work with, but that did not matter to anyone - why? And if so, why does it matter there is legacy code someplace that breaks if a planned move is made X years from now re: some other semantics. Why this discrimination? What is this, some kind of an animal farm where some are more important than others?
Or in another way of thinking, I worked with the team in anticipation of Fortran 2023 years from now to redesign and refactor the code so that it will not break - it has to with objects of CHARACTER type with the ALLOCATABLE attribute and their use in certain language statements and intrinsics. The team bore the cost and moved on even as the business expectation is likely this code will migrate away toward .NET or modern C++ by the time robust Fortran 2023 processors come along years from now. So if this team can absorb the cost of change, why cannot others?
Under the circumstances then, given the sheer recalcitrance and reluctance with any positive help with the situation from the voting members of the J3 committee, a significant majority of whom tend to be vendor reps, and mere slow dragging of feet to enable status quo with the defaults, the above statement comes across more as a “shot across the bow” rather than a statement of fact. I was utterly dismayed to read last night.
There are times when creative destruction is absolutely necessarily for progress. The situation with the defaults in the Fortran world is calling for this, cue this thread - thanks to @Pap for bringing it up and to @omacl for reviving it. To do so and it can be done in a planned manner, over a span of 10 years or so after which certain things are simply allowed to “break”. However there is no true support for this from the bearers, even as a matter of principle, and that is the real problem.
It is backwards to think of LFortran, or any compiler for that matter, as driving such a change of de facto conventions or of the fortran standard itself. The real driving force is always the programmers, the user base of the language. If the community wants one convention, and LFortran opposes that, then that division will be harmful to the fortran community. This was the problem in the 1980s with the fortran standards process, the programmers wanted one set of features and the vendors wanted something else, and that conflict almost killed the language. On a smaller scale, that is what happened to the F and ELF dialects in the 1990s, the vendors wanted to provide one thing, and the programmers wanted something else.
Of course, I admit that what the programmers want isn’t always the best option. But please, avoid the conflict within our community whenever possible.
Yes, I as well assume that to be a prerequisite. It may not have been clear from my message.
FWIW, Intel Fortran inherited its FREEFORM and NOFREEFORM directives from DEC Fortran.