Has the Fortran committee considered making the line continuation operator & optional? It makes some Fortran codes verbose. Younger programming languages like R and Julia don’t have a line continuation operator.
1 Like
Would this be restricted to cases where a line by itself is not valid Fortran? You could write
i = i1 + i2 + i3 + i4 + i5 +
i6
which could be useful for expressions with many terms. The freedom to write
i = i1 + i2 + i3 + i4 + i5
+ i6
would reduce legibility IMO and be difficult to compile.
1 Like
Yes. You are right. This should be the way to go. I also use this style in R and Julia even though it is not required.
@fortran4r can you (and others!) please upvote this issue:
And read the discussion there.
2 Likes
I personally have no problem with using & as a continuation operator. But from a legibility POV it would help if it could (optionally) be placed at the start of the continuation line rather than at the end of the one that is to be continued. Would make it easier to keep the &'s vertically aligned.
While can start with them aligned at the end of a line, edits to the code can quickly mess up the alignment. Then have to re-align to keep the code tidy or leave them mis-aligned.
You want
j = 1 +
End
to be valid Fortran?
1 Like
Other popular languages have similar rules for line continuation, for example in MATLAB:
s = 1 - 1/2 + 1/3 - 1/4 + 1/5 ...
- 1/6 + 1/7 - 1/8 + 1/9;
I’m interested if people also complain about line continuation when they (or their universities/employers) buy MATLAB licenses. I get a feeling when a language (compiler) is available for free, we all feel entitled to complain about it’s design and function.
If I recall correctly Python has implicit continuation in things such as bracketed expressions, lists, strings, or function headers (syntax elements that are bracketed in some way). For example the following Python code:
a = 3 + 6
+7
print(a)
a = (3 + 6
+7)
print(a)
will produce the following output
$ python test.py
9
16
This might provide a partial answer to the example above discussed by @Beliavsky and @themos.
2 Likes
It does not have to be free; call it Fortran, and everyone will complain. Reinvent Fortran and give it a new name. Everyone will love it because it is fashionable and justifies the writing of multi-million dollar grants to port existing stable infrastructure to the latest fashionable language.
3 Likes
I also feel typing a lot of & is sometimes very tedious, but the request to remove it might be a bit similar to asking removing ; (semicolon) in C++ …? (looking at newer languages without semicolons)
1 Like
Are there cases where optional line continuations could create ambiguities? I have spent half an hour trying to construct one and it is not easy. So far my best effort is:
real elemental
function foo(bar)
Which could mean that elemental is a real variable and foo is an implicitly typed non-elemental function, but there is nowhere in code where that sequence of statements could occur. More work for the compiler, but I think it might work.
John
1 Like
Currently you can do:
subroutine integer
integer subroutine, endsubroutine
endsubroutine &
= subroutine/subroutine
endsubroutine &
;
But in the parser, you simply parse until the end of statement (either new line or ;), so the above is equivalent to:
subroutine integer
integer subroutine, endsubroutine
endsubroutine = subroutine/subroutine
endsubroutine ;
And there is no ambiguity. Without & however, you get:
subroutine integer
integer subroutine, endsubroutine
endsubroutine
= subroutine/subroutine
endsubroutine
;
So it becomes a lot tougher, how does it know that endsubroutine is and end of subroutine and not a variable? Well, you would get a syntax error at the next line I guess. It could also be arbitrarily nested like:
subroutine integer
integer subroutine, endsubroutine
endsubroutine
= subroutine/subroutine
endsubroutine
= subroutine/subroutine
endsubroutine
= subroutine/subroutine
endsubroutine
I guess the new rule would be that you parse it as long as it make sense?
1 Like