Succinct statement end

[fortran4r]

Has the Fortran committee considered making statement ends more succinct? end do => end [optional do], end if => end [optional if], etc. Matlab and Julia both have this feature.

I showed my Fortran example codes to one of my colleagues who only uses Matlab, and he immediately found the statement ends verbose and distracting. He is pretty senior (got his Ph.D. in the 1990s) but still finds Fortran syntax undesirable. This is really concerning given that the young generation of programmers tends to have a much higher standard for programming language syntax.

[shahmoradi]

This discussion appeared before. For the moment, the answer seems to be no. and I do not think that will change, since it appears to be significant extra work for the compiler developers only to stop non-Fortran programmers from nagging about the verbosity of a language they have never used and will likely never use.

There is a significant limitation with constructs in MATLAB and Julia (and almost any other language) where Fortran shines. And that is the ability to exit any construct at any nesting level by labeling the construct. It’s a true time-saver when dealing with ten nested loops and if-blocks, where deep in the blocks, the programmer can exit all nested levels at once by a single condition check. Try implementing the same in MATLAB or Julia, and that will require 30 extra lines or more to achieve the same goal.

[fortran4r]

@shahmoradi

And that is the ability to exit any construct at any nesting level by labeling the construct.

I totally agree that labeling can be useful. But, changing end do to end (and end if to end) does not affect the labeling feature.

[Beliavsky]

In my codes I always use

end program foo
end module foo
end function foo
end subroutine foo
end interface foo

even when just end would suffice, so that it is glance clear what is being ended. If both end do and end if could be replaced by end, it would not be clear just from that line whether an if block or a loop was being terminated.

Someone should not move to a new language and expect it to work exactly the same as the old one. Matlab is convenient for small programs, but I doubt it scales well for large ones. I think the Matlab restriction of one public function per file, with the same name as the file, is bad.

[fortran4r]

@Beliavsky

If both end do and end if could be replaced by end , it would not be clear just from that line whether an if block or a loop was being terminated.

Matlab and Julia are totally OK with this feature. Fortran IDEs like Geany, Code::Blocks, and VSCode can easily match ends with constructs. Even if you use a bare-bone editor, using proper indentation can help find the matching struct.

This end do and end if design is simply another piece of historical baggage, just like implicit none. Making it optional will not even break backward compatibility.

[MarDie]

@fortran4r

This end do and end if design is simply another piece of historical baggage, just like implicit none.

I don’t agree. implicit none is required because the default setting in the language does not reflect what most people want. end XXX enforces the programmer to write code that is easier to read. It is like a comment embedded into the language. In terms of the Zen of Python: explicit is better than implicit.

[ivanpribec]

I’ve seen cases of C or C++ codes before, where the programmers add comments to the closing brackets or preprocessor end statements, e.g.

inline do_test()
  {
    #if (TEST == 1)
      do_something
    #endif  //TEST == 1
  }

More commonly, it is done for namespaces, where the brackets might span several dozens or hundred of lines of code. An example from nanoflann:

#ifndef NANOFLANN_HPP_
#define NANOFLANN_HPP_

namespace nanoflann {

// ... thousands of lines of code ...

} // namespace nanoflann

#endif /* NANOFLANN_HPP_ */

Judging by the following blog post, this also appears to be something people do in R to help identify pairs of brackets:

Auto-label closing parentheses in RStudio by Matt Dray

So the answer what is better is not clear cut. Personally, I like having the extra visual information on what construct ends. I don’t think getting rid of two characters would impact my productivity in a language. I think I spend more time reading documentation, and thinking about how to code something. So calling this historical baggage seems exaggerated.

As @Beliavsky noted one should try to approach a language with an open mind, without his own bias baggage from previous languages. Of course the same holds in the other direction too.

I’ve found a paper related to this topic:

Chen, J. (2018). Linguistic Relativity and Programming Languages. arXiv preprint arXiv:1808.03916 . [1808.03916] Linguistic Relativity and Programming Languages

in which the author quotes a paragraph from Whorf:

[E]very person […] carries through life certain naïve but deeply rooted ideas
about talking and its relation to thinking. Because of their firm connection with
speech habits that have become unconscious and automatic, these notions tend to be intolerant of opposition.

The authors continue:

Replace “talking” with “writing code”, and the analogy between speech and computer programs could hardly be plainer. An experienced programmer, practically by definition, internalizes the boilerplate and design patterns in code as “unconscious and automatic” idioms to be regurgitated on demand (preferably with an editor or IDE that helps reinforce these idioms automatically). To the fluent Java programmer, wrapping everything in a class must be second nature, just as the R user is accustomed to seeing data in a data frame, or whitespace sensitivity to the Pythonista. Allowing for code as a generalization of speech, one could argue that Whorf’s observation predicted the very phenomenon of flame wars over programming language design!

[Beliavsky]

@MarDie

end XXX enforces the programmer to write code that is easier to read. It is like a comment embedded into the language. In terms of the Zen of Python: explicit is better than implicit.

Yes, and I have proposed that the language be extended to allow end do to be followed by the name of the loop variable, so that one could write

do i=1,n
   do j=1,m
      ! stuff
   end do j
end do i

This would be helpful in long loops, and it would be more concise than the labels currently allowed and also less error-prone, since with labels one can write the misleading

loop_j: do i=1,n
   loop_i: do j=1,m
      ! stuff
  end do loop_i
end do loop_j

Visual Basic allows

for i = 1 to n
   for j = 1 to m
      'stuff
   next j
next i

[msz59]

There are at least two other constructs in which end XXX is required: interface and block. I have no problem with adding XXX to end and I second the opinions that in general it makes the code clearer. On the other hand I have been always wondering why this asymmetry exists that some constructs have the XXX optional and some not. Maybe there is some deeper, syntactical reason for that?

[mecej4]

In Fortran 77 and earlier, the END statement had only one purpose: to end a subroutine, a function or a main program unit. The F77 standard says:

“An END statement is written only in columns 7 through 72 of an initial line. No other statement in a program unit may have an initial line that appears to be an END statement.”

Then came Fortran 90, and we had the IF… END IF, DO … END DO and other constructs that needed an END xxx. How should a compiler writer accommodate the END xxx terminations of these constructs, and at the same be able to compile older Fortran source, which had to satisfy the above rule?

Thus, backward compatibility, which is a benefit at times and a source of difficulty at other times, may have made it necessary to add a suitable “xxx” to distinguish such an END xxx from the old END.

A programmer today may argue that the asymmetry is not essential, but the compiler writer may say, “maybe so, but having the xxx made my task much easier”.

[vmagnin]

I now try to follow the Fortran stdlib Style Guide:

The convention adopted herein is to include procedure names, module names and program names in the end statement, unless the closing statement can reasonably be expected to be on the same screen or page, within about 25 lines.

[msz59]

@mecej4

“An END statement is written only in columns 7 through 72 of an initial line. No other statement in a program unit may have an initial line that appears to be an END statement.”

Then came Fortran 90, and we had the new IF… END IF, DO … END DO constructs. How should a compiler writer accommodate the END xxx terminations of these constructs, and at the same be able to compile older Fortran source, which had to satisfy the above rule?

The old source had to satisfy it but not the newer compiler. As it is able to compile new source which has as many end statements not ending the program unit as the programer puts in, it could also compile old source which had no such end-s

Also (though irrelevant): if ... then ... endif construct was already part of F77.

[fortran4r]

I am also puzzled by this asymmetry and inconsistency.

[FortranFan]

@fortran4r

I am also puzzled by this asymmetry and inconsistency .

Welcome to what’s now a mystical world of Fortran!

Almost like a volcano, the language convulses through its phases of strictness and relaxation and thus far, there has been no discernable pattern to the evolution other than it follows the tug and pull of mostly compiler vendors (influenced perhaps by “large” $$ contract customers who are often mostly government labs funded by taxpayers’ money) and a few practitioners from large institutions who are (un?)fortunate to sit through in-person standard revision meetings.

Consider Fortran 90 thru’ 95 until 2003 revision: end function and end subroutine: starting with all the new-fangled stuff introduced in Fortran 90 such as internal subprograms and MODULEs and what-not, the committee decided FUNCTION and SUBROUTINE had to be specified with module as well as internal procedures.

Come Fortran 2008, there was realization this wasn’t quite necessary and with the needs of “auto” generated code, this can actually be inconvenient. Thus the constraint was removed.

So you have this situation:

! main program with internal subprogram
contains
   subroutine sub()
   end
end 

C:\Temp>gfortran -c -std=f95 p.f90
p.f90:4:6:

4 |    end
  |      1

Error: Fortran 2008: END statement instead of END SUBROUTINE statement at (1)
p.f90:5:3:

5 | end
  |   1

Error: Fortran 2008: END statement instead of END SUBROUTINE statement at (1)
f951.exe: Error: Unexpected end of file in ‘p.f90’

C:\Temp>gfortran -c -std=f2008 p.f90

C:\Temp>

It’s possible with enough attention and systematic review of modern processors (parsers, compilers, etc.), the situation can be relaxed for many other constructs that require the END-statement.

However, pending an autocatalytic outpouring of extreme care and consideration toward the convenience of poor, persevering practitioners of Fortran, such time and attention ain’t going to be forthcoming.

[mecej4]

What has been discussed in this thread is mostly about what kind of syntactic sugar should be required or used, with differing opinions on the flavor. There is no disagreement at all on semantics, is there?

Perhaps the solution is not to attempt to get the language to be changed, but to develop tools (filters/preprocessors) that are used directly by the user or invoked by the compiler as requested with a matching option, in order to convert “succicnt source” to standard-compliant source. Some users, in fact, may be satisfied if the IDE/source-editor displays end when it sees end if in the source file, and so on?

[certik]

@mecej4

Perhaps the solution is not to attempt to get the language to be changed, but to develop tools (filters/preprocessors) that are used directly by the user or invoked by the compiler as requested with a matching option, in order to convert “succicnt source” to standard-compliant source. Some users, in fact, may be satisfied if the IDE/source-editor displays end when it sees end if in the source file, and so on?

Yes I think this is the only way forward. To implement such new features in a compiler first, and add a capability to transpile the extended Fortran back into standard Fortran so that it can be compiled with other compilers also. We already do a version of this with fypp in stdlib.

[ShrirajHegde]

This just seems to reduce readability a bit but doesn’t off much comfort at all.

Even though program, function or subroutine statements can have just end, it still makes much more sense to take 2 more seconds to select the suggestion and end with the name.

A significant part of python’s success is the formatting, which makes it much harder to write poorly formatted code. So I would argue highly against this. Also, because of line truncation in Fortran, you can’t always use indentation very freely (disabling in compiler will require compile instructions)

Some C and cpp even python codes where functions are too long, the end of the function name is mentioned with a comment.

void foo(type bar){
.
.
.
.
.

} //end of function foo

So this is a good thing to have. Especially with long functions.

[septc]

Though it might be already mentioned above, I think “end” + additional info is useful only when a code block is rather long (say, when it does not fit in one terminal screen), while I feel it is rather annoying to see/read for short blocks, e.g. when the body of a function or construct has only a few lines. In the latter case, I think “end” with no additional info is just fine.

Btw, Python even does not have “end”, but I prefer having something to terminate a block… (though some people really seem to like having no such symbols).