Language version keyword

[aradi]

There are several features in Fortran many of us wish to see changed / deprecated in order to support and enforce modern programming practices (see for example . Unfortunately doing so would break backwards compatibility of the language, which would sacrifice one of Fortrans advantages.

What about adding a keyword to the language, which indicates the language version of the code in a given unit (module). Something like:

module my_modern_module
  language_version 2022
 ...
end module my_modern_module

All module files without explicit language version keyword would be treated as having code complying to the last standard without this keyword (e.g 2018). All module files with the language version keyword would be treated accordingly to the specified version.

Advantages:

• One could deprecate features much faster without fearing to break backwards compatibility.
• The user would not have to deal with compiler specific flags to enforce a given practice or language standard (like -assume realloc_lhs or similar). Especially, if you have source files with different language standards in a project (no nice, but can happen), you won't need to fiddle with the compilation options for each file individually.
• A single line could enforce several requirements without too much verbosity, so instead of having

  implicit none(type, external)
  implicit save off
  short_circuiting on
  ...
  

  one would just write

  language_version 2022
  

  to profit from all the features / requirements a given Fortran standard offers / enforces.
• Finally, its marketing value would tremendous. Every source file in a modern Fortran project, every slide presented in a Fortran course, would advertise, that this beautiful language, despite being the first high level (modern!) language, is still alive and is able to adapt to the requirements of the present.

[FortranFan]

@aradi , please see this thread at comp,lang.fortran where a similar idea re: a 'version specifier' was posted.

While I am personally not sold yet on the specific keyword idea (I wonder if a simpler semantic alternative might be attainable for the same), I wholeheartedly agree with and support your sentiment you express, particularly in your last bullet, toward Fortran language. The relevance of Fortran in scientific and technical programming is profound and hope it can remain as such, its strength lies in both in its legacy but more importantly with the potential for the future that can allow scientists and technologists to focus almost exclusively on their domain expertise and their computations without having to get their hands "dirty" with the nitty-gritty details and artifacts of computer engineering (pointers, LValue/Rvalue, etc.)

[aradi]

@FortranFan Thanks for the link, I was not aware of that discussion. By looking at it, I could not find any serious counter arguments, why this idea can not be or should not be done.

As for the keyword itself: If there is any other superior semantic solution, we should go with that then. For me, it is only important that we can adapt the language to current programming customs faster. While every programming language has its own peculiarities, those peculiarities should have a good justification other than we always did this way. As I mentioned on the other issue here, I am often feeling ashamed, when explaining to students that they must put implicit none in every module (especially if their project should pass the exam 😆 ).

[sblionel]

I don't have strong feelings one way or another about the general idea, but I will caution that standardizing keywords such as standard version numbers is fraught with risk for compiler developers and users. Consider that the name of Fortran 2018 changed in the year or so before publication. What you would end up with is either vendors having to support multiple, synonymous keywords (some of which would not be conforming in the new standard), or delaying support until the standard is published meaning a delay before programmers could use them.

There is also the issue of incomplete implementations and TSes, assuming a TS changed the meaning of a past standard (unlikely but it could happen.)

See also my 2013 thoughts on a related topic.

[certik]

Available options

In Fortran, we do not break old code (#79), so the only way to introduce a breaking feature is to signal to the compiler that the given source file is using the new feature, and by default no signalling is done, so the old feature is being used. So the only question is how to signal to the compiler. Here are the options that I have seen proposed:

1. File suffix specifying a version (.f90, .f03, .f08, .f18, .f2x, .f2y)

2. Compiler option for the version (-std=f95, -std=f18, -std=f2x)

3. Compiler option for a feature (-frealloc-lhs, -fimplicit-none, ...)

4. Keyword for the version (this issue Language version keyword #83)

5. Keyword for a specific feature (implicit none, implicit save off (see Deprecate and remove implicit save behavior #40), ...)

6. Keyword for modern (modern module X) which would not use obsolete features (features can become obsolete in the future and one would need to update the code)

Is there fundamentally any other way to consider?

Analysis

The option 1. does not seem to be a good way as @sblionel explained here, and I agree.

The option 2. is already used in compilers such as gfortran, but my understanding is that the standard does not enforce new features, so even with the latest -std=f18, the feature implicit none is not enabled unless explicitly told so. In other words, the newest standard does not break old code. So the options 1., 2., and 4. actually cannot impose implicit none, unless F202x or F202y introduces a breaking change of enabling implicit none by default, and historically this is not how we have done things. But unless that is changed, you would still have to do:

language_version 202x
implicit none(type, external)
implicit save off
short_circuiting on
...

That leaves options 3. and 5., both of which one can use today, but the problem with these is that as more and more optional features are added, it will be more and more painful to be always explicitly enabling them at the beginning of each module, such as:

implicit none(type, external)
implicit save off
short_circuiting on
...

The objection from Steve regarding the fact that the name of the standard changes until it is released is easily fixed by simply using the placeholder -std=f2x, until F202X is released and then changing it to -std=f23 (for X=3). That's how C++ does it and f2x just becomes an alias for f23. I think that's not a problem in practice.

So the main issue that I can see in here is that some future standard, say 202y will introduce a breaking change such as enabling implicit none by default. And if you tell the compiler (no matter whether using an option -std=f2y, or by using a keyword language_version 2y), then the new feature will be used by default. That is a fundamentally different way of doing it --- and that's what we should discuss if we want that.

Update: added option 6.

[aradi]

@certik That's a nice summary on the possible options, thanks! One note on the topic, whether to realize it via compiler option or language construct: I think, a programming language should be self-contained. A compiler should be able to generate correctly behaving code (and stop on standard violation) just by reading the source code itself without the need of any additional hints in form of command line options. Latter should in my opinion only serve 'fine-tuning' purposes instead of being indispensable for the correctness of the generated code.

[aradi]

And yes, I would vote for breaking backwards compatibility in newer standards for the sake of simplicity and code robustness, provided a standardized language construct ensures that old code can be still compiled without the necessity of using extra (vendor dependent!) compiler options.

[certik]

@aradi so let's discuss some of the breaking features that could be considered:

• Deprecate and remove implicit save behavior #40
• Short-circuiting logical expressions #19 (however it seems it won't pass, and instead .andthen will be introduced which is not a breaking feature)
• realloc LHS

Anything else? Because if it's just these, then there might be a way to achieve what we want without breaking backwards compatibility (for example #40 can be fixed by changing "implicit none" to "explicit all" or something like that --- still just one line to be added to every module), so we do not need the feature discussed in this issue.

[gronki]

I will be the devils advocate here, since I am usually the hater on the old code, but I will argue that this solution is inherently dangerous.

First, let me prefice that with what I consider the absolutely basic design feature I expect Fortran to have: prevent silent errors. So ugly syntax or not, what I personally get paid for is to get good numeric results.

Consider the very root of such solutions, which probably is the familiar line

implicit none

The implicit typing feature was deemed to be unsafe and thus new, stricter rules for typing can be enabled with this switch. Please notice:

1. if you omit the implicit none, the functionality of the code will not change
2. if you use -fimplicit-none (or equivalent) switch, the functionality of the code will not change

Reading the code mid-file, you don't need to check the top of the file to see the implicit none. You just use the implicit typing and whether this mode is enabled or not, you will be good. Now if you start using implicit typing and implicit none was in effect, you will get a compiler error. All good.

Now consider the proposed switch (let's stick to my favorite implicit save). For example:

implicit nosave

If you do that, the behavior of the code will change violently in a completely non-distinguishable way. Whenever you see:

integer :: i = 0

you have no idea whether i will be zero on each call or not. And worst of all, if you make a mistake, you will not be warned.

Now when you work with different files, some of them written in 1980s, other in 2010s, you cannot just write right Fortran: you have to keep in mind which typing/saving/... rules are in place. Which is exactly the reason why implicit typing was deemed unsafe!

As much as I hate and despise this feature, I think we cannot provoke such situations. It must be clear looking at the code whether the variable is save or not. A couple of solutions have been proposed:

1. integer, nosave :: i = 0 -- IMO pain to type
2. integer, init :: i = 0 -- nicer to type on QWERTY keyboard
3. integer :: i := 0 -- or some other operator, such as =>. The good side is that there are no keywords that clutter the code.

Any solution must be nice to type. This keyword/syntax will be used a lot. So I personally would prefer some operator-based syntax because having nosave every 3 lines would cause a lot of clutter, especially in editors with syntax highlighting. But the worst case init would be not that much pain.

Now this ended up being an implicit save post which I didn't intend but I did not know how to split it so maybe I will post exactly the same thing in the other place.

[certik]

@gronki thank you. These are precisely the kinds of arguments that we have to have. I commented at #40 (comment) with my proposal there.

[klausler]

@aradi so let's discuss some of the breaking features that could be considered:

• Deprecate and remove implicit save behavior #40
• Short-circuiting logical expressions #19 (however it seems it won't pass, and instead .andthen will be introduced which is not a breaking feature)
• realloc LHS

Anything else? Because if it's just these, then there might be a way to achieve what we want without breaking backwards compatibility (for example #40 can be fixed by changing "implicit none" to "explicit all" or something like that --- still just one line to be added to every module), so we do not need the feature discussed in this issue.

That list could be a lot longer. All "deleted" and most "obsolescent" features could finally be disabled (e.g., EQUIVALENCE, Hollerith, extensions like STRUCTURE) in a program unit that declares itself to be "modern".

Syntactically, this sort of thing might look best as a prefix on the MODULE statement, i.e. MODERN MODULE FOO. And it should be inherited and enforced in submodules.

[certik]

@klausler, that's a great idea. Perhaps the standard can simply declare some features as "obsolescent", and those would work by default, but if you use modern module foo, all "obsolescent" features will get disabled.

One problem that I can see is that when a future standard makes something "obsolescent" and you happen to use that feature in your modern module foo, your code will break. And you cannot just remove modern, because you use some other "modern" features, so your code will simply stop working until you fix it. I think that's a problem.

[aradi]

@gronki I think the point you raise is absolutely right. Having a language version keyword would indeed make the behavior of certain constructs "context-dependent". Actually, we have that already in the language, since

integer, allocatable :: a(:), b(:)
...
a = b

triggers LHS reallocation depending whether you stick with Fortran 95 or 2003. And, which one of the both is used, depends on the compiler options you use for compilation. There is no way to tell it by looking at the source code alone. The language keyword would at least let you know it by declaring the standard conformance at the beginning of your scope.

[aradi]

@klausler Thanks, indeed the list could be considerably longer. And I agree that it is a good idea to encode the standard compliance already into the module statement. However, I'd suggest to keep it general with possibilities for future adjustments, so using something more specific as modern, e.g.
module, language(f2008) :: my_module
or something similar.