Implicit typing and backwards compatibility

23

It is just what I said before. If you put the appropriate IMPLICIT statement in the code one time, then it works correctly from now on. If you don’t put that in the code, then you must add the compiler option every time the code is compiled, from now to eternity.

25

If it is such a big deal to add a compiler flag, why don’t we move forward from the .f90 file extension?
One option would be to actually enforce the usage of .fxy to enable a specific standard. Or we come up with a “new” file extension for all upcoming standards. Some examples:

  • .ff: free form
    • collides with Call of Duty 4 Fast File and Farbfeld Image
  • .mf modern Fortran:
    • collides with Panda Multifile, Java Manifest File and METAFONT File
  • .fff free form Fortran
    • collides with Hasselblad RAW Image, MAGGI Face File and Gravis UltraSound Sound Bank
  • .fl Fortran lang
    • collides with Freelancer Saved Game File and FLUID GUI Design
  • .ft Fortran
    • collides with Edgecam Feature Template
2 Likes
26

I think this should be up to the compiler and not specified by the standard, and compilers already have options to specify the standard being followed. A user should not have to change the suffix of a source file to use a feature from a later standard. One reason is that it would make source control more complicated. C++ programmers do not use a file suffix to indicate the standard employed.

1 Like
27

I, too, would prefer a suffix that doesn’t have to change.
But it would be an option to make a cut. For example, if you use .ft the compiler could throw an error if deprecated features are used. So if you want to keep all the implied/implicit behaviour, just continue to use .f and .f90, but if you want implicit none to be the default, just chose the .ft suffix.

I don’t think it’s a good idea to allow compilers to do what they want with the suffix because then we will soon have to rename our source files whenever we want to use another compiler.

1 Like
29

There is also a subthread here about the file suffix. I still think we should just use .f for modern Fortran (Reclaiming `.f` file extension for modern Fortran (free form) · Issue #363 · fortran-lang/fpm · GitHub). For now I’ll leave the thread here, we can split it into a dedicated thread later if needed.

1 Like
30

Regarding implicit typing (I split this into a dedicated thread here), @RonShepard and @kargl, would you be interested in having a video conversation about this? It would greatly help me understand exactly your points, and we can have a quick back and forth to get on the same page regarding these issues (others are welcome to join as well). We have more agreement than you might think (for example all three of us seem to agree that old code must run unmodified and must just work), and it might be that we disagree on some points, but it would be nice to understand exactly what those points are.

1 Like
31

It may be useful to have a list of all the tools that can add explicit typing to old code that don’t have them. If there are some with a free license have them shipped with the stdlib (or fpm, or whatever) may help the transition.

If I have to touch an old code I don’t do that before adding an implicit none to all the routines.

1 Like
33

I think the lack of agreement is in how to reconcile the need of many (myself included) to have “implicit none” by default in practice, without breaking things. One option is to keep the Fortran standard as is; and have this implemented by vendors (one way or the other).

34

Only “assigned goto” is deleted, the other two are obsolescent.

Nonetheless a conforming processor is required to

  1. “to detect and report the use within a submitted program unit of a form or relationship that is not permitted by the numbered syntax rules or constraints, including the deleted features described in Annex B;”
  2. “detect and report the use within a submitted program unit of a form designated herein as obsolescent, insofar as such use can be detected by reference to the numbered syntax rules and constraints;”

I reckon a good conforming processor then will detect and report all the deleted features like “assigned goto” and when it can, per its will and inclination to follow the standardese, it will do the same with obsolescent features.

Programmers, of course, can take actions (e.g., “-std=legacy” with gfortran) and force the processor to be nonconforming and suppress the detection and reporting but that is entirely on the users.

My plea is within 10 to 20 years at least from now, Fortran arrive at a stage where

  1. implicit mapping is removed and thus implicit none becomes the default (users can still employ explicit IMPLICIT statements, no problem) and
  2. assignment-based initialization on type declarations without SAVE attribute be disallowed i.e., only eliminate implicit SAVE that is associated with type declaration plus initialization is (users can include explicit SAVE attribute with the initialization on declaration if they so choose, no problem).

In order to achieve the above vision, one has to start now and petition to include this in Fortran 202Y which will be published at an unknown date from now, but what is likely around year 2030.

This is not about cost, it is entirely about benefits.

Fortran benefits greatly by evolving to a better language that by default strives toward explicit all, starting with types and external procedures but also with static data (SAVE state).

The backward compatibility comes in where existing codes are given the option to implement changes to conform to the new processor viz,

  • introduce IMPLICIT INTEGER(I-N), REAL(A-H,O-Z) statement in their program units and interface bodies,
  • add the SAVE attribute to the type declarations that have assignment-based initialization.

This is the sacrifice the legacy codes must be asked to make for the future of Fortran e.g.,

  • instead of expecting all future generations to include IMPLICIT NONE in all the program units and interface bodies, let the legacy codes include IMPLICIT INTEGER(I-N), REAL(A-H,O-Z) statement in their programs if they want to conform.
3 Likes
35

@certik, your optimism remains commendable about the hope a solution can be developed without breaking changes!

I, for one, had long “jumped” to the conclusion it is not possible to achieve progress without a breaking change.

I firmly believe this now requires “rip the bandaid off” approach by around year 2030 at least by when the “bandaid” of implicit none has been hoisted upon all users against the cut of implicit mapping.

Why not finally turn it the other way around and require the legacy codes to make the sacrifice for the future of Fortran e.g.,

  • instead of requiring all future generations to include IMPLICIT NONE in all the program units and interface bodies when they want the benefits of explicit typing, etc., let the legacy codes who have relied on implicit mapping include IMPLICIT INTEGER(I-N), REAL(A-H,O-Z) statement in their programs if they want to conform.

The number of such legacy codes who have consciously relied on implicit mapping are so few and far in between that the benefits of this change will be far, far greater than the cost.

The notion that one cannot make a breaking change to the standard is clearly untenable, one can try to minimize it but not completely avoid it.

With elimination of implicit mapping, one must be willing, I believe, to finally let the legacy codes “break”. In principle that is, because in practice the bearers of such codes know their processors will continue supporting their legacy ways. Nonetheless, in principle, the legacy codes can unbreak themselves with the IMPLICIT INTEGER(I-N), REAL(A-H,O-Z) statement if they so choose, or by adding IMPLICIT NONE themselves to avail of further benefits. But please, free the future generations of Fortran from being forced into using IMPLICIT NONE, that is just bad, bad, bad to continue to force this on new users. My plea to the Community here is to fully adopt this line of thinking.

2 Likes
37

No one is going to stop using Fortran if implicit none becomes the default. I think you are making this more complicated than it is. People using old code can enable the compiler flag to get default implicit typing back.

Right now, implicit typing is joke, an embarrassment, a continuing source of errors and confusion for new programmers. Year after year, decade after decade. This fact cannot simply be ignored. Enough is enough. It’s more important for the future of Fortran to get new users onboard. Make the people who want to compile unchanged 60 year old code have to do one minor thing, rather than making everybody else suffer until the end of time, while Fortran becomes less and less relevant to scientific computing. I don’t want page 1 of every Fortran tutorial to have to explain this ridiculous feature anymore. It’s time to move on.

It’s a no brainer to me. But I don’t know if the committee would agree. Frankly I’m pessimistic based on recent history.

11 Likes
38

It’s actually much more likely that the default will continue to be the old behavior, and you’ll be forced to set a compiler flag to get the new standard-conforming behavior – for one major compiler at least.

40

And the solution is to add one compiler argument and then it all works fine for them again. What am I missing here? Why do you think these people should be allowed to hold up progress for decades because they can’t add a single trivial flag to their build system? I don’t get it.

6 Likes
41

The whole argument re: OASES is not relevant to the proposal to make implicit none the default.

The codebase toward OASES does not conform at all to the Fortran standard, a cursory glance at the first file I picked randomly shows:

  1. rank mismatch in arguments, the file I picked had an actual argument of rank-2 where the dummy argument was a scalar. This is something the Fortran standard has never supported. One will be hard pressed to find a current processor support it readily, one will have to invoke various extensions (e.g., via compiler options such as -std=legacy) to get past the compiler errors.
  2. The code uses arithmetic IF statement which has already been deleted from the standard starting Fortran 2018,
  3. The code also uses a nonblock DO construct, again something that has been deleted since the Fortran 2008 revision,
  4. Type mismatch between REAL actual argument vis-a-vis COMPLEX dummy argument, an error.
  5. Use of Hollerith H edit descriptor, yet another deleted feature from the standard.

Elimination of implicit mapping will be the least of the problems for OASES looking at the code, if anything it will be a major blessing!

The code needs refactoring at a major level - for US Navy, I will be willing to do it for free with utmost respect for all those who have served!

Next,

2 Likes
44

I don’t want to engage in an argument but I want to try summarize the major points of this discussion to try to understand this better myself:

  • Between implicit mapping and implicit saveing, deleting the former would be less harmful to legacy code than the latter (which is trickier to debug BTW);
  • The major point for enabling implicit none everywhere by default is that this is annoying (agree) and a source of confusion for people who aren’t used to Fortran, and expect the compiler to dump an error if you don’t declare a variable type;
  • In both cases, things could be relatively easily handled with compiler flags (they already do for implicit none), that would warn the user (and maybe in future revisions, to stop the compilation) either way.

The question whether it would be more impactful to either break existing code, or to simplify current/future Fortran programmer’s life, will never have an answer.

Something I haven’t seen discussed is (my $0.02):

  • implicit none is just one of many Fortran verbosities, like contains, like simple recursive pure elemental double precision very_long_function(), like endassociate, not really a problem;
  • All IDEs (including CodeBlocks that I use) have templates, they put in code for you, so you don’t have to type it every time. Same thing that everybody does for C++ headers, they also have a lot of bloat to avoid annoying features from the standard (even worse: using the preprocessor)
  • I would like to see implicit none to go, but I don’t think that’s one of the reasons a young programmer would choose not to pick Fortran up instead of Julia, Python, etc. I don’t think young programmers are such proficient object-oriented gurus that they care about complex inheritance issues, or tiny performance gains. IMHO what those other languages have as an advantage is: 1) readily-available libraries; 2) “Matlab-like” array syntax.

So, sorry for the long read; to me, maybe implicit none doesn’t deserve that much energy, that’s it.

5 Likes
45

Would that rule apply also to top level declarations in PROGRAM unit? That would be really awkward to be forced to put SAVE in that context. On the other hand, making this rule different for PROGRAM top level and other contexts would make even bigger mess.
IMHO there is no good fix to the (obvious I guess) error that was made introducing implicit SAVE attribute in the declarations with initializers. What has come to my mind is maybe we could add UNSAVE declaration/attribute, similarly to SAVE. Then, adding UNSAVE declaration without any list of objects would allow to use INTEGER :: par=23 legally, without implicit SAVE attribute. Alternately, one could write INTEGER, UNSAVE :: par=23

1 Like
46

Please define “without any changes”: it doesn’t seem to be the case at all. You appear to not realise that only two lines above you just admitted to be forced to use -std=legacy to compile OASES. It’s a matter of updating that flag for gfortran in the scenario discussed. IMO, that makes total logical sense: that’s legacy code, it already is and should be identified as such.

4 Likes
49

Ok, interesting. Thanks for the details and for trying to make the latest standard the default for gfortran: I obviously wholeheartedly agree with it.

So, based on this description, it looks like that the majority of gfortran maintainers are interested in keeping gfortran, not only non-standard conforming, but riddled with many deleted features. Curious, but it looks more like a problem with gfortran than with the proposal discussed here.

I am not sure I understand what you’re trying to prove here. You pulled out a legacy code from Netlib (the place described by @jacobwilliams with an expression that cannot be perfected further: “where Fortran codes go to die”) and you seem to discover that you receive errors when you turn on strict Fortran 2018 conformance. Really?! Obviously, no one is foolish enough to even try compile legacy packages with strict conformance to the latest standard. There’s nothing to grep, the outcome is obvious from the outset.

Apart from that, quoting verbatim Jack Dongarra (at page 12): “Sca/LAPACK is written in Fortran and uses archaic software engineering techniques”. Let’s say, with an understatement, that I don’t find this counter-example particularly compelling…

2 Likes
51

I think adding all these file extensions is more or less the same as trying to standardize compiler options. Further, as each possibility is added, the number of combinations, or the number of file extensions, will grow exponentially. This does not seem like a practical solution to the problem.

Also, something that should be obvious, is that a file extension like .ff is confusing because it could stand either for “fixed form” or “free form”.

Back in the 1980s I used a fortran compiler that allowed every one of its options to be set either on the command line or embedded in the code as a compiler directive. After using this feature for just a short time, I realized that it was almost always better to add the compiler directive in the source code than it was to use the command line option. The reason, was that once it was in the code, it was always there, permanently, and it only had to be added once. If it were a command line option, then it was required every time I compiled the code. Most of these were optimization options, so the code was “correct” either with or without the directive, but sometimes there were cases where incorrect code was produced without the option, so it was critical to get the right combination of command line options or compiler directives. That is easier to do with directives in the code, which are more or less permanent, rather than the more temporary approach of command line options.

1 Like
52

The reason is that the legacy codes have already been written. The codes are already published in journal articles and textbooks, they are already distributed across the internet on numerous servers, and so on. That is what “legacy” means, they are already there, and one cannot go backwards in time and change all of that.

When an inexperienced programmer combines such legacy code with newly written code, and conflicts arise because of the change in default implicit types, then that will be a barrier to the continued use of the fortran language. This would not be some short term problem, like “ripping off the bandaid”, where things will heal and gradually get better, that conflict will continue to occur from the moment the default is changed for all of eternity. I think this wound, to continue the analogy, will never heal.

I’m mostly talking about the change to implicit typing here. To a lesser extent, it also applies to the default save problem. I say lesser extent here only because that is a more recent feature in the language, dating back a decade or so, while the implicit typing feature goes back decades (some 60+ years).