fix Fortran code with lines that are too long

[Beliavsky]

I have come across some free source form Fortran code that has some lines that are too long (more than 132 characters). It compiles with the gfortran -ffree-line-length-none option.

Has anyone written a program that fixes Fortran code with this problem by breaking up overly long lines and using continuation lines?

[Sjouke Burry]

On 13-5-2018 3:38, Beliavsky wrote:
> I have come across some free source form Fortran code that has some lines that are too long (more than 132 characters). It compiles with the gfortran -ffree-line-length-none option.
>
> Has anyone written a program that fixes Fortran code with this problem by breaking up overly long lines and using continuation lines?
>

What stops you from writing one?

[Dominik Gronkiewicz]

W dniu niedziela, 13 maja 2018 03:38:51 UTC+2 użytkownik Beliavsky napisał:
> I have come across some free source form Fortran code that has some lines that are too long (more than 132 characters). It compiles with the gfortran -ffree-line-length-none option.
>
> Has anyone written a program that fixes Fortran code with this problem by breaking up overly long lines and using continuation lines?

Not an answer to your question, but you can always add this compiler switch permanently in Makefile. In my project, a use the following line:

FFLAGS += -pedantic -fimplicit-none -ffree-line-length-none

Line length limitation is archaic and I wouldn't care about it too much in 2018 :)

[Gary Scott]

No, line length limitation is not archaic. It is sensible and
reasonable, and expected.

[Dan Nagle]

Hi,

On 2018-05-13 15:54:33 +0000, Gary Scott said:

> On 5/13/2018 8:29 AM, Dominik Gronkiewicz wrote:

<snip upstream>

>> Not an answer to your question, but you can always add this compiler
>> switch permanently in Makefile. In my project, a use the following line:
>>
>> FFLAGS += -pedantic -fimplicit-none -ffree-line-length-none
>>
>> Line length limitation is archaic and I wouldn't care about it too much
>> in 2018 :)
>>
> No, line length limitation is not archaic. It is sensible and
> reasonable, and expected.

I disagree.

In a world of automatically generated code, line length limits
are indeed archaic.

For example, consider

sed -e "s/__FILE__/$FILE/" -e "what goes here?" <some-file >some-other-file

How to do line wrapping?

(And sed is Turing-complete, see https://en.wikipedia.org/wiki/Sed for more.)

(And don't say sed is not used for preprocessing;
one cannot build the Gnu compilers without invoking sed as a preprocessor
to prepare header files.)

The last thing Fortran needs is a pointless final step in
automatically-written Fortran.

--
Cheers!

Dan Nagle

[spectrum]

I hope that compilers allow any line length because a source preprocessor
can generate a very long line (well over 132 characters, for example).

But from the viewpoint of code readability, I agree with the idea that
it is better to keep the line length to below a certain length (say 80),
so that it fits well in a terminal window etc.

# "finally, a monitor that will fit the entire name of my Java classes" (just a joke :-)
https://twitter.com/t045tbr0t/status/972275166611898368

So, I think there are two different contexts: one is from compilers, and the other
is from "coding style". For the former, I think line limitation is archaic (i.e., the
compiler is expected to allow any line length), while for the latter context
line limitation is not archaic (i.e., some "user-defined" limitation is desired
to keep readability).

So, the meaning of "archaic" maybe depends on the context...

https://www.python.org/dev/peps/pep-0008/
https://www.python.org/dev/peps/pep-0008/#maximum-line-length
https://stackoverflow.com/questions/88942/why-does-pep-8-specify-a-maximum-line-length-of-79-characters

[Gary Scott]

Any output process that produces non-human readable source form is
broken. Having to scroll right through thousands or tens of thousands
of characters is just dumb. Use a little imagination.

[spectrum]

PS. For clarity, I'm just referring to some discussion on a "recommended" line
length in some other languages (as a coding style, not a compiler limitation),
which many people have different ideas (depending on one's preference).

I guess the reason why some recent codes use a long line (than before) is that,
the monitor becomes wide and recent editors support automatic completion
of long variable/routine names. A former group member in my group liked to use
a very wide terminal, and he always sent to me a wide Readme text, which
I always struggled to read in my narrow terminal :-) (We talked on this several
times, but he after all preferred to use such a long-line style, so it depends really on
preference...) I remember some developer of MD codes also prefer this style
(like 200-char width window).

---
Btw, to fold lines into shorter ones (for use with a compiler that does not support
> 132 chars), maybe we can split lines by words and just insert "&" + new line char
around 80--100 etc? (using awk or python or something). Hope such a program is
already available...

[Ev. Drikos]

On 13/05/2018 22:42, spectrum wrote:
> I hope that compilers allow any line length because a source preprocessor
> can generate a very long line (well over 132 characters, for example).
>
> But from the viewpoint of code readability, I agree with the idea that
> it is better to keep the line length to below a certain length (say 80),
> so that it fits well in a terminal window etc.
>
> # "finally, a monitor that will fit the entire name of my Java classes" (just a joke :-)
> https://twitter.com/t045tbr0t/status/972275166611898368
>

Java has a limit of approximately 65K method size, which might be very
restrictive for certain applications, ie a generated parsing table for a
large grammar like SQL.

Oh, Fortran poses similar limitations with statement continuation
patterns, call me '&'. Of course there are always workarounds and
alternative solutions and admittedly I don't need sth like that at the
moment.

I've found in past, online discussions that ifort supports tables large
enough (likely smaller than 32MB though). So someone else felt that 512
lines of source code ie isn't that much.


Regards,
Ev. Drikos

[Ev. Drikos]

On 14/05/2018 01:55, Ev. Drikos wrote:
> ...

>
> I've found in past, online discussions that ifort supports tables large
> enough (likely smaller than 32MB though). So someone else felt that 512
> lines of source code ie isn't that much.
>
>

(repeated)

I've found in past, online discussions that ifort supports *statements*
large enough ...

[Dominik Gronkiewicz]

I sparked quite a discussion! I probably used word which is a little too strong :) However I stand by my point. Most programmers understand the reason for line wrapping and hold onto the 80 character rule (so do I), and the rest has editors that do the wrapping for them.

I think that imposing an artificial limit on line length to "keep the code style good" is a bit contradictory with other more important issues where Fortran standard leaves plenty of space for code to be dead ugly.

Code generation (including preprocessing!!) mentioned by Dan Nagle is another big point -- in work we use sympy to generate Fortran code to evaluate derivatives of very complex expression. Line wrapped or not, they are equally unreadable. Luckily, sympy does the line wrapping by itself, but in other cases one needs to implement not-so-trivial algorithm that will fold the lines. For no good reason, in my opinion.

Luckily, all compilers provide an available option to disable the line limit :)

[JCampbell]

I don't like long lines of code fro a number of reasons.
They can be very difficult to audit and also difficult to use in a debugger.
breaking up the long statement improves checking.
The recent post on order of calculation and omission of some functions
demonstrates it is more uncertain in longer code statements.
I have used compilers where register overflow can be a problem with long lines.

Be concise and make the code easier to maintain.

[Dominik Gronkiewicz]

> I don't like long lines of code fro a number of reasons.
> They can be very difficult to audit and also difficult to use in a debugger.
> breaking up the long statement improves checking.
> The recent post on order of calculation and omission of some functions
> demonstrates it is more uncertain in longer code statements.

Well, you can still make long statements by using the & continuation sign. So I don't see where imposing an artificial limit helps here. Fortran is the only modern language that I know of that imposes this kind of weird restriction.

> I have used compilers where register overflow can be a problem with long lines.

It's a compiler bug, so I cannot see what it has to do with the language. :)

[Dan Nagle]

Hi,

Your editor doesn't wrap lines for you?

The sed example below was carefully chosen:
It will work most of the time in C, but will have difficulties
much more of the time in Fortran.

If wrapping is done the easy way, the result may split tokens.
Some may find that split tokens are hard to read.
If wrapping is done to be more readable, it's hard to do right.

Nothing stops you from writing short lines if the limit
is large. Many compilers today allow *much* longer lines than 132.
Evidently, there is some customer demand.

I note you did not comment directly on the sed example.
You merely imply that a lack of imagination on my part
is somehow related to deficiencies in your chosen editor.

--
Cheers!

Dan Nagle

[Thomas Koenig]

JCampbell <campbel...@gmail.com> schrieb:

> I have used compilers where register overflow can be a problem with long lines.

Are you still using Turbo Pascal? :-)

[Terence]

"Beliavsky" wrote :-

Yes, I have a parser program to rewrite Fortran code; replace Hollerith
literals found anywhere; rewrite lines to not pass position 71 without
continuations; separate shared CONTINUE lines by providing separated lines
and new unused labels; change all labels used anywhere to a increasing
sequenced set starting at any supplied number; and report any original
label numbers not referred to; and report any parsing errors found. Any many
more selectable options.

Drawback: it writes F77 code because that is what I use with my trusty
bug-free compiler; but there is a well-known F77 to F95 translator by Alan
Miller that can be used next for those who wish to invite trouble.
Many "Fortraners" already have and use this.

[Terence Cosgrove]

Hi
Do you have a copy of your parser I could try? I have a very old and very long .for program
and is suffers form both long lines and hollerith statements.
Thanks
Terry

[David Jones]

A possibly useful start might be "tidy" which has the following
description:

TIDY version 7.2, 1999-10-15

Function:
TIDY 7.2 is a highly configurable FORTRAN program to indent and
renumber statements, selectively change case of keywords or
non-keywords, and do various other clean-up tasks on FORTRAN-77
source programs. TIDY can convert some FORTRAN-66 features such as
Hollerith constants to FORTRAN-77. TIDY can either retain DO/END DO
loops or convert them to standard FORTRAN-77 loops. It can change
comment specifiers from C,c,or * to ! as in F90 style. Supports F90
CYCLE, EXIT, DO WHILE loops, IMPLICIT NONE, INCLUDE statements,
long variable names, the relational operators <,>,<=,>=,
==,/= and the use of underscores in variable names.

It is not clear if it will deal with long lines but at least it deals
with Hollerith constants.


It an be obtained from

http://www.pdas.com/tidy.html

but the "official" link mention therein no longer works.

I think You would need another program to promote code to free format
and later coding proclivities.

[Terry Cosgrove]

[Terry Cosgrove]

On Friday, October 16, 2020 at 5:24:10 PM UTC+1, David Jones wrote:

Hi
Many thanks for your suggestion I have downloaded the program and will give it a try
Terry

[Edmondo Giovannozzi]

Il giorno domenica 13 maggio 2018 alle 03:38:51 UTC+2 Beliavsky ha scritto:
> I have come across some free source form Fortran code that has some lines that are too long (more than 132 characters). It compiles with the gfortran -ffree-line-length-none option.
>
> Has anyone written a program that fixes Fortran code with this problem by breaking up overly long lines and using continuation lines?

A simple Python program is:
MAXLINELENGTH = 30

def split_line(line):
out = []
while line:
out.append(line[:MAXLINELENGTH])
line = line[MAXLINELENGTH:]
return out

def limitfortranline(fid):
for line in fid:
splitted_line = split_line(line)
if len(splitted_line)>1:
yield splitted_line[0] + "&"
for ll in splitted_line[1:-1]:
yield "&" + ll + "&"
yield "&" + splitted_line[-1]
else:
yield splitted_line[0]

I haven't checked it much but it uses the fact that you can prepend a "&" to the continued line and if you do this you can split everything from names, strings, etc.

[JCampbell]

At a minimum, I would want to:
# know how many lines were too long, and
# have a parser that at least identified if the extension was only an in-line comment.
Surely this is not difficult to write in Fortran, especially in a clf forum !

I do note that gFortran V10.2 does report the line number of lines that are too long (it might stop reporting if there are too many?)

[Thomas Koenig]

JCampbell <campbel...@gmail.com> schrieb:

> At a minimum, I would want to:
># know how many lines were too long, and
># have a parser that at least identified if the extension was only an in-line comment.
> Surely this is not difficult to write in Fortran, especially in a clf forum !

To each their own tool. I would probably prefer awk or Perl for this:

$ awk 'length > 132 { print } ' foo.f90

will print all the long lines.

Comments are a bit more tricky to parse.

print *,"! Here is not a comment" ! But here...

Also, it is debatable if you want to ignore long comments as
possible errors. OpenMP (and OpenACC) directives are technically
comment lines, and these are supposed to be cut off after column
132 in free form...

[JCampbell]

On Sunday, November 29, 2020 at 2:46:04 AM UTC+11, Thomas Koenig wrote:
>
> Also, it is debatable if you want to ignore long comments as
> possible errors. OpenMP (and OpenACC) directives are technically
> comment lines, and these are supposed to be cut off after column
> 132 in free form...

Interpretation of OpenMP directives is an interesting area for compiler diagnostics, especially as they are technically comment lines.

With gFortran, I use -fimplicit-none and !$OMP PARALLEL DO DEFAULT (NONE) ... in an attempt to enable diagnostics for !$OMP directives.
(I am hoping to get a report if any variable/array used in the $OMP region is not identified as PRIVATE or SHARED, or identified variable is not used.)

This is an area where more explicit compiler reporting could be provided, as errors in the directive can be ignored or the directive can be totally ignored, with no warning.
Restricted syntax for $OMP, especially in fixed format code, can lead to the directive being ignored and no warning (apart from no thread generation at run time).
Is there any guidance as to how to improve $OMP compiler reporting ?

[Thomas Koenig]

JCampbell <campbel...@gmail.com> schrieb:

> Is there any guidance as to how to improve $OMP compiler reporting ?

Maybe the other way around: If you have a test case where you
think that error reporting should be improved in gfortran, you could
submit an enhancement PR.

(I don't use OpenMP myself much, so I cannot really comment a lot
otherwise).

[John]

Unless this does not get accepted, I think using the ubiquitous switches for allowing longer lines might not be as
risky as a lot of extensions, as the top of the J3 committee reads as follows last I knew ...


WG5
From: J3
Subject: US Feature list proposals for F202X at the end of M218
Date: 14-March-2019

This paper summarizes the US National Body list of requested features
for the next revision of the Fortran standard, aka F202X. Many of these
proposals have J3 papers with detailed requirements, descriptions and/or
edits. No priority order is implied.


I. Source Form changes.

US01. Allow much longer statement lines and overall statement
length. (m218: 19-138r1, 11-1)

US02. Require the processor to report cases where over-long lines or
statements result in lost information. (m218: 19-149r1, uc)

[Steve Lionel]

On 12/5/2020 5:36 AM, JCampbell wrote:
> Interpretation of OpenMP directives is an interesting area for compiler diagnostics, especially as they are technically comment lines.

Our (DEC/CPQ/Intel) interpretation was that directives were "statements
with funny syntax", and we treated them as such, doing appropriate
diagnostic reporting. If the prefix was something we recognized, it was
considered a directive, which means that unrecognized directives (!DIR$
FOOBAR for example), gave a complaint.

--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

[John]

Surprised no one has mentioned the NAG Fortran polisher which I heard good things about, but have no experience with. I have been told that it converts fixed to free format and allows a width to be set. Curious if anyone tries it or has experience with it. I believe something like it might be in the plans for FLang, but I think that is just in the "possible plan" stage. On the surface at least it sounds like it would clean up your issues.