Fortran 2018 Standard - file extensions [.for and .f or f90, f03, f15, f22]

[Mohammad]

This may seem an odd and duplicate question, but having a standard for fortran source file extensions can help to have a model. It is known that the Fortran standard is quiet about file on disk for source code.

see these pages

Steve Lionel
https://software.intel.com/en-us/blogs/2013/01/11/doctor-fortran-in-source-form-just-wants-to-be-free

Arjen Markus
http://fortranwiki.org/fortran/show/File+extensions


The good suggestion by Steve Lionel is to stick with .f90 as free source format for all new generation of Fortran from 1990 onward, but why not to mit the year attached to extension to have a universal file extension.

One suggestion is to use:
.for for fixed form and
.f for modern fortran (like .c for C language)

It does not have a year attached to the extension.

We know that on some systems .f and .for both are used for fixed-form code, but Fortran 2018 standard can propose this and compilers can have switch to supprot
old codes and previous libraries use the old convention.

Or you may propose a new extension to be used for Modern fortran or free-form source code.

What do you think?

[kergonath]

Hi,

I think that it is very unfortunate that the de facto standard file
extension references an outdated standard. It also is very unfortunate that
some compilers insist on making us jump through hoops to process anything
else.

The best proposal that I have seen so far is to use .ff for free-form
Fortran (we don’t want to tie that to a particular version of he standard,
though), and .FF for a file that needs to be pre-processed. All the other
obvious choices have already other meanings and using them would cause
unnecessary issues. For example, at least in the autotools, a F77 compiler
is called by default for both .f and .for files (which is also very
unfortunate for other reasons, but anyway). This can be changed, but this
is a nuisance. It is much easier to just add another extension for
free-form sources.

Cheers

[Clive Page]

On 14/01/2018 17:36, Mohammad wrote:
> The good suggestion by Steve Lionel is to stick with .f90 as free source format for all new generation of Fortran from 1990 onward, but why not to mit the year attached to extension to have a universal file extension.
>
> One suggestion is to use:
> .for for fixed form and
> .f for modern fortran (like .c for C language)

I agree it's a bit odd to continue using .f90 for code written to more modern standard such as 2008, but this has become something of a de-facto standard.

The problem is that old Fortran source code hangs around for a long time, and I have many files with .f as the extension which were written many years ago for the fixed-format convention, typically Fortran77. So adopting this now to identify free-format code would be very confusing.


--
Clive Page

[FortranFan]

On Sunday, January 14, 2018 at 12:36:39 PM UTC-5, Mohammad wrote:

> .. It is known that the Fortran standard is quiet about file on disk for source code.
>
> ..
.. .f and .for both are used for fixed-form code, but Fortran 2018 standard can propose this and compilers can have switch to supprot

> old codes and previous libraries use the old convention.

> ..
>
> What do you think?


I think you will find little support for any of this in terms of the Fortran standard. As you write, the standard does not cover any such aspect and to me, it makes to keep it that way.

Besides the existing users who have long been using .f for their fixed-form code are not going to take at all kindly to "compilers can have switch to supprot old codes and previous libraries use the old convention" and rightly so, the "cost of change" with any such thing will never add up to any benefit in any budget controller's mind.

Separately, file extensions can be viewed as a convention followed by coders: .f90 has taken hold for free-form source code. A thought I had several years ago, but which found few takers in the team(s) I worked with at the time, was to use

.mf instead of .f90 for free-form Fortran source code

May be you will consider it and start using it! Then a few others might start following it also leading to a new convention eventually!!

[Mohammad]

@Cleve and @Kergonath

If you take a look at
https://fileinfo.com/filetypes/common

Having four characters as file extension is a common practice (like .html), this is also valid on Linux and Mac OS so if the [.f] is can not be used due to the vast amount of fixed formed code in .f files we may suggest this

.mfor -> Modern Fortran, free form source code

This is a new extension and has been not used before.
The standard can set rules for
- fixed form
- need to be pre processed
- other type ...


what do you think?

I believe it worth to put some time and push people in Standard committee to make decision on this.

[Mohammad]

Good Suggestion @FortranFan!
.mf or .mfor both seems good!

[FortranFan]

On Sunday, January 14, 2018 at 1:00:43 PM UTC-5, kergonath wrote:

> ..

> The best proposal that I have seen so far is to use .ff for free-form

> Fortran .. and .FF for a file that needs to be pre-processed. ..

Some OS platforms such as Windows are case-insensitive with file names, so any casing based convention will run into barriers.

That's why I was leaning toward

.mf for free-form Fortran source code

where 'm' is homage to the transformation to modernity starting with the Fortran 90 standard.

.ff runs into an issue because the first 'f' can imply either free or the fixed-form.

[FortranFan]

On Sunday, January 14, 2018 at 1:34:08 PM UTC-5, Mohammad wrote:

> ..

> Good Suggestion @FortranFan!
> .mf or .mfor both seems good!

On Sunday, January 14, 2018 at 1:30:22 PM UTC-5, Mohammad wrote:

> ..

> I believe it worth to put some time and push people in Standard committee to make decision on this.

Cool!

The first step for you might be to convince Intel Fortran team and gfortran to accept such an extension(s) by DEFAULT i.e., have the compiler commands automatically treat files such an extension as free-form source. These two are likely constitute the largest user-base for modern Fortran. If they include such support, other compiler implementations are more likely to follow.

Then you start to develop a ground-swell of support for the file-naming convention, a must for any eventual consideration by the standards committee.

With gfortran, you can become a volunteer, join the team, and even implement the changes yourself!

All the very best, keep up your great efforts with coding using modern Fortran!

[Mohammad]

@FortranFan
Is it possible to get feedback for at least people in this group to see what they think (poll or survey in group)? like a petition and send to standard committee!
It also possible to ask gfortran developer to support .mf or .mfor for modern fortran source code and as you said it leading to a new convention eventually!

[Mohammad]

Good idea!

[Mohammad]

A poll is created! I start a new Post to start the poll!

[Mohammad]

See this new post:

https://groups.google.com/forum/#!topic/comp.lang.fortran/St6qWh71dW0

[kergonath]

FortranFan <pare...@gmail.com> wrote:
> On Sunday, January 14, 2018 at 1:00:43 PM UTC-5, kergonath wrote:
>
>> ..
>> The best proposal that I have seen so far is to use .ff for free-form
>> Fortran .. and .FF for a file that needs to be pre-processed. ..
>
> Some OS platforms such as Windows are case-insensitive with file names,
> so any casing based convention will run into barriers.

Conventions based on case already exist and have been used for quite some
time now. I think all the compilers I have used would call the preprocessor
when provided a file with an extension in upper case.

>
> That's why I was leaning toward
>
> .mf for free-form Fortran source code
>
> where 'm' is homage to the transformation to modernity starting with the
> Fortran 90 standard.
>
> .ff runs into an issue because the first 'f' can imply either free or the fixed-form.
>
>
>

“Modern” is not very descriptive, though. Hopefully the number of
fixed-form files created from now on will be negligible so confusion should
be minimal in any case.

[kergonath]

I suspect you will find that nobody is entirely satisfied but getting the
compiler vendors to do something like that would be a major task, never
mind having the standards committee agreeing too. This topic pops up
regularly.

[Wolfgang Kilian]

Please, don't.

Steve's blog post is still valid. Like it or not, .f90 has been
established as the default extension for free-form format. The damage,
if any, has been done. There are countless editor/build setups and
build systems that rely on this choice.

Fixed-form source files will continue to be included in Fortran projects
and should be recognizable by name. So .f is taken.

And .mf is particularly bad because .mf is the suffix for Metafont code,
which you will find on all Linux systems, at least.

-- Wolfgang

[FortranFan]

On Sunday, January 14, 2018 at 3:08:08 PM UTC-5, kergonath wrote:

> ..

> Conventions based on case already exist and have been used for quite some
> time now. I think all the compilers I have used would call the preprocessor
> when provided a file with an extension in upper case.
>

Intel Fortran on Windows does NOT "call the preprocessor when provided a file with an extension in upper case."

> ..
> “Modern” is not very descriptive, though. ..

Sure "modern" by itself is one of the most overused terms in English since the time of Shakespeare, but in the highly limited world of Fortran, it's understood well enough and there are even book titles to point to:

Modern Fortran Explained - Michael Metcalf, John Reid and Malcolm Cohen, Oxford University Press, 2011, ISBN 978-0199601417
Renaissance

Modern Fortran: Style and Usage - Norman Clerman and Walter Spector - Cambridge University Press, 2012, ISBN 978-0521514538

Numerical Computing with Modern Fortran - Richard J Hanson and Tim Hopkins - SIAM, 2013, ISBN 978-1-611973-1-2

Modern Fortran in Practice - Arjen Markus - Cambridge University Press, 2012, ISBN 978-1-107-60347-9

[Steve Lionel]

On 1/14/2018 3:48 PM, Wolfgang Kilian wrote:
> Please, don't.
>
> Steve's blog post is still valid.  Like it or not, .f90 has been
> established as the default extension for free-form format.  The damage,
> if any, has been done.  There are countless editor/build setups and
> build systems that rely on this choice.

My opinion on this matter hasn't changed since I wrote that blog post.
The last thing we need is yet ANOTHER file type that some compilers
support and some don't. I always tell people who ask that one of the
major strengths of Fortran is the huge body of existing code for reuse -
mucking about with file types will just introduce headaches.

As for putting something like this in the standard - not gonna happen.
The standard makes a point of NOT specifying implementation details of
this kind. I will also note that not all platforms use the "extension"
convention of filenames to designate file type.

As I wrote in the post, it's too bad that we didn't think about this 30
years ago, but that ship has sailed. I do, sort of, like the idea of a
marker in a source file - as others have said, most compilers support
this in various implementation-dependent ways.

Is it really such an awful thing to type .f90?

--
Steve Lionel
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: http://intel.com/software/DrFortran

[FortranFan]

On Monday, January 15, 2018 at 12:51:31 PM UTC-5, Steve Lionel wrote:

> ..

> The last thing we need is yet ANOTHER file type that some compilers

> support and some don't. ..
> .. I do, sort of, like the idea of a marker in a source file ..

> most compilers support this in various implementation-dependent ways.

Well, a file extension is NOT a type. See an example of perceived file types on Windows:
https://msdn.microsoft.com/en-us/library/windows/desktop/cc144150(v=vs.85).aspx

If a coder is piping a source file that is in TEXT file format to a processor and is WILLING to provide a compiler option (e.g., -ffree-form) or a marker, then the file extension should NOT matter. Yet, a couple of compilers issue errors which is not "doing right by" the coders:
https://en.wiktionary.org/wiki/do_right_by


gfortran:
--- begin console output ---
C:\temp>type p.f
print *, "Hello World!"
end

C:\temp>gfortran -ffree-form p.f -o p.exe

C:\temp>p.exe
Hello World!

C:\temp>type p.mf
print *, "Hello World!"
end

C:\temp>gfortran -ffree-form p.mf -o p.exe
c:/program files/codeblocks/gfortran/bin/../lib/gcc/x86_64-w64-mingw32/8.0.0/../
../../../x86_64-w64-mingw32/bin/ld.exe:p.mf: file format not recognized; treatin
g as linker script
c:/program files/codeblocks/gfortran/bin/../lib/gcc/x86_64-w64-mingw32/8.0.0/../
../../../x86_64-w64-mingw32/bin/ld.exe:p.mf:1: syntax error
collect2.exe: error: ld returned 1 exit status
--- end console output ---



Intel Fortran:

--- begin console output ---
C:\temp>type p.f
print *, "Hello World!"
end

C:\temp>ifort /free p.f
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R
) 64, Version 18.0.1.156 Build 20171018
Copyright (C) 1985-2017 Intel Corporation. All rights reserved.

Microsoft (R) Incremental Linker Version 14.12.25831.0
Copyright (C) Microsoft Corporation. All rights reserved.

-out:p.exe
-subsystem:console
p.obj

C:\temp>p.exe
Hello World!

C:\temp>type p.mf
print *, "Hello World!"
end

C:\temp>ifort /free p.mf
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R
) 64, Version 18.0.1.156 Build 20171018
Copyright (C) 1985-2017 Intel Corporation. All rights reserved.
ifort: command line warning #10161: unrecognized source type 'p.mf'; object file
assumed

ipo: warning #11010: file format not recognized for C:\temp\p.mf

Microsoft (R) Incremental Linker Version 14.12.25831.0
Copyright (C) Microsoft Corporation. All rights reserved.

-out:p.exe
-subsystem:console
p.mf
p.mf : fatal error LNK1107: invalid or corrupt file: cannot read at 0x21
--- end console output ---

[kargl]

FortranFan wrote:

> On Monday, January 15, 2018 at 12:51:31 PM UTC-5, Steve Lionel wrote:
>
>> ..
>> The last thing we need is yet ANOTHER file type that some compilers
>> support and some don't. ..
>> .. I do, sort of, like the idea of a marker in a source file ..
>> most compilers support this in various implementation-dependent ways.
>
>
> Well, a file extension is NOT a type. See an example of perceived file types on Windows:
> https://msdn.microsoft.com/en-us/library/windows/desktop/cc144150(v=vs.85).aspx
>
> If a coder is piping a source file that is in TEXT file format to a processor and is WILLING to provide a compiler option (e.g., -ffree-form) or a marker, then the file extension should NOT matter. Yet, a couple of compilers issue errors which is not "doing right by" the coders:
>

> C:\temp>type p.mf
> print *, "Hello World!"
> end
>
> C:\temp>gfortran -ffree-form p.mf -o p.exe
> c:/program files/codeblocks/gfortran/bin/../lib/gcc/x86_64-w64-mingw32/8.0.0/../
> ../../../x86_64-w64-mingw32/bin/ld.exe:p.mf: file format not recognized; treatin
> g as linker script
> c:/program files/codeblocks/gfortran/bin/../lib/gcc/x86_64-w64-mingw32/8.0.0/../
> ../../../x86_64-w64-mingw32/bin/ld.exe:p.mf:1: syntax error
> collect2.exe: error: ld returned 1 exit status
> --- end console output ---
>

You are not piping the file to the a processor, here. gfortran is not
the processor. It is the compiler driver that sets up the enter
chain of convert Fortran code into an excutable. The compiler is f951.
I can't find in the documentation where .mf is an accepted file
name extension.

--
steve

[FortranFan]

On Monday, January 15, 2018 at 7:48:01 PM UTC-5, kargl wrote:

> ..
>
> You are not piping the file to the a processor.. can't find in the documentation where .mf is an accepted file
> name extension.
>


My bad, wrong choice of words in terms of piping.

Indeed .mf is not an accepted file extension, but that's the point.

The very concept of an "accepted file extension" is a limiting one for higher languages, it's jaded, appears borne largely out of the development on Unix with a systems programming language, the so-called "lesser one"!!

Can not Fortran do better? Why should it matter whether a coder names a source file foo.for or foo.bar for or even foo it to be compiled? :-)

[campbel...@gmail.com]

On Tuesday, January 16, 2018 at 11:48:01 AM UTC+11, kargl wrote:

> I can't find in the documentation where .mf is an accepted file
> name extension.
>
> --
> steve

For gFortran, gcc.pdf documentation in section "3.2 Options Controlling the Kind of Output" lists the file name suffix that determine what kind of compilation is done. Fortran suffix that are recognised are : .f .for .ftn for fixed format and .f90 .f95 .f03 .f08 for free format.
This can be modified using the -x f77 or -x f95 option, although I have not used this option. ( not referred to as f90 ? )
.mf is not listed as recognised in my documentation.

[campbel...@gmail.com]

The following works for my windows implementation
gfortran -x f95 p.mf -o p.exe -v

[Mohammad]

Result of survey:
By now (Jan 23, 2018) 30 votes received and 56.7% proposed .f90 as the modern fortran file extension and not .f90, .f95, f03, f08, ...
Few people voted for .fort or .mf, or .mfor.
The result can be accessed from below link

https://goo.gl/PMbx1c

[FortranFan]

On Tuesday, January 23, 2018 at 1:28:29 PM UTC-5, Mohammad wrote:

> ..
>

> Result of survey:
> By now (Jan 23, 2018) 30 votes received and 56.7% proposed .f90 as the modern fortran file extension ..

Thanks for sharing the responses thus far.

What is shown at second post in red at 10%? There are a couple of them in similarly looking red color, so it's unclear. Is it the .f option at #2 spot?

[Mohammad]

The #2 spot is belong to .mf
Unfortunately Google form does not allow controlled access. By the way see the link below
https://docs.google.com/forms/d/1uk5-JaxAUj98AD3CPd4OGWorIpQZ8dX_vzecKppvxb0/edit?usp=sharing