I sympathize. All I can hope is that increasing the number of Fortran users, and people actually wanting to write modern Fortran code will somehow lead to more gfortran contributors. I’m doing my best. But I don’t know.
1 Like
I thought the post related to the added complexity in IMPLICIT NONE, by including “type” and “external”.
For all the complaints about the use of IMPLICIT NONE, and the suggestions of selecting a compiler flag for Fortran version, can I point out that -fimplicit-none is also a compiler option on most compilers and perhaps it’s use should also be recommended.
Every time I compile Fortran code, I use a number of options, including -fimplicit-none.
What are all these feigned complaints.
Intel’s compiler doesn’t have an equivalent to -fimplicit-none. They have one for warning about implicit typing, but not one to make it an error (unless they added something recently that I don’t know about).
With Intel, it’s split across two options: -warn declarations -warn errors
i = 42
end
C:\Temp>ifort /c /warn:declarations /warn:errors p.f90
Intel(R) Fortran Intel(R) 64 Compiler Classic for applications running on Intel(R) 64, Version 2021.3.0 Build 20210609_000000
Copyright (C) 1985-2021 Intel Corporation. All rights reserved.
p.f90(1): error #6717: This name has not been given an explicit type. [I]
i = 42
---^
compilation aborted for p.f90 (code 1)
But again, the question is this: why should one have to resort to something OSTD (outside the standard) to enforce something a significant fraction of the Fortran codebases seek earnestly which is simply explicit declarations? If not now, why during circa 203X which is the earliest a change in Fortran 202Y might see the light of day?
Which important codebase is out there that will see a processor change to that based on Fortran 202Y but which can’t be updated to have implicit integer(i-n), real(a-h,o-z) statement(s) in it? Or which cannot go with the equivalent of fno-implicit-none? That it is so important that everyone else has to keel over and include implicit none all over theirs?
I think adding the support for namespace is much more important/useful than removing implicit none.
Have no idea why implicit none suddenly becomes a problem just because the author of that article seems intended to belittle Fortran 
For me implicit none simply reminds everyone the glory history of Fortran. It is a unique trademark of Fortran.
If I remember correctly, in the program or in the module, one just need to type implicit none once at the beginning. No need to type implicit none everywhere.
There are many more important things to do than implicit none.
PS.
I mean, come on, that U(t) in below eqn,
does not have to be just a trivial 1-d number.
How about if U(t) is a n-element vector? The solution is same, just think of U(t) as a vector.
So, let us compare the speed of these languages for n=10**8, t from 0 to 25, shall we?
2 Likes
I agree with that. To me it seems that in the discussion implicit none is just a proxy to comment on the evolution of Fortran.
My (biased) summary of the discussion is the following: Nobody thinks that implicit none is a great feature, but it stays because removing it is associated with the following issues:
- The removal needs to be implemented into compilers
- It will break backward compatibility
I can’t comment on 1), but as written before having a versioned standard makes it trivial (from the user side) to cope with breaking changes in the standard. All compilers that I know of have the feature to select the version of the standard to use for compilation. Still, the barrier for removal of features from the standard is extremely high. This is something I don’t understand
Everyone accepts that a modern operating system can’t be installed on a 30 year old computer, but it seems unacceptable that Fortran code from 1995 does not compile with -std=2018. Why?
5 Likes
I remember that I had to change some code (adding results(...)) when setting the standard to 2018. I tried to reproduce this, but I couldn’t. Maybe it was a false positive or I remember it wrongly.
Anyways, it seems that my perception was wrong.
Support for something like a namespace facility, or anything else is not impacted by introducing explicit declarations as the default in the language.
It’s not a zero-sum game (or any of its variants) when it comes to Fortran language evolution.
1 Like
Yes, I have worked with many legacy codebases in industry whose origins range from 1960s thru 1970s and 1980s up until the 1990s.
None of the codebases employed Fortran’s implicit mapping facility on purpose.
Each and every codebase either had explicit IMPLICIT statements, the most common among the older codebases being IMPLICT INTEGER(I-N), DOUBLE PRECISION(A-H,O-Z); the codes that saw refactoring starting around 1980s or were authored after the 1970s all had IMPLICIT NONE.
Moreover the coding manuals/style guides/notes all indicated to the programmer to explicitly declare all variables, etc. and to use implicit none. Among the first points made to the coders in all those documents is "Use Implicit none in each program unit, and explicitly declare all variables and parameters.".
It is no wonder really the MILITARY STANDARD 1753 FORTRAN, DoD Supplement To American National Standard X3.9-1978 document extended the IMPLICIT statement to include implicit none, the need to support explicit declarations was noted and recognized nearly 45 years ago.
Chances are near 100% there is NOT a single codebase out there which is being updated to work with newer Fortran processors and which employs Fortran implicit mapping on purpose and/or cannot be updated to introduce implicit integer(i-n), .. over the next couple of decades.
There are no legitimate arguments against standardizing something finally in Fortran 202Y (preferably) or 203X (latest) that has been the strongly recommended starting point of almost every any codebase since MIL-STD 1753 i.e., implicit none. Not doing this defeats the entire purpose of the standard, one does not need to look at any NDAs to understand this, or to hesitate on this.
Separately the entire recertification argument is a red herring if not entirely bogus in the context of implicit none discussions. Fortran keeps getting shelved while the standard process returns too little, too late. Entire codebases migrate away to other languages and achieve the certifications and move on in far less time than it takes for the Fortran committees to arrive at a consensus on anything.
1 Like
The bar for a nonbreaking change is set so low the jury shall be out for a while when it comes to the Fortran 2018 extension that makes every procedure RECURSIVE by default.
First note, it will take 10+ years from now for Fortran processors to generally implement the Fortran 2018 change with any degree of robustness and that too only with additional switches.
Note Intel Fortran for example does NOT intend to make RECURSIVE the default compiler facility until well past the distant future. Users will have to apply -assume recursion or -standard-semantics to get the standard extension which they may or may not realize for a long, long time. Once they do, it won’t be long before they have to apply NON_RECURSIVE clause to any number of procedures to ensure the code does not break - so much for backward compatibility.
So there is no need to quickly concede on your argument or any biases.
Animal farm it always is: some are more equal than others. It’s the same when it comes to backward compatibility arguments in Fortran. Some aspects such as implicit mapping get treated as more equal only because of strong biases in their favor, or against others.
There is another “less troublesome” option regarding whether IMPLICIT NONE should become implicit (or “default”, as @FortranFan says) or whether the current implicit convention should live on.
Many compilers allow the user to keep a small file in a known location, or to set an environment variable, either of which contains a string of compiler options. For example, on Windows Ifort looks up a file called “IFORT.CFG” in the compiler’s bin directory, and mine contains
/MD /traceback /warn:errors,declarations
This has the same effect as adding an explicit IMPLICIT NONE in all the places in the source code where it is required.
Forcing long-time users to change the way that they use a compiler is usually a risky step for a compiler vendor to take. It is often the compiler that gets blamed for errors caused by a change in the operating system, bugs in a third party library or even long-lived bugs in the users’ code that get exposed after a compiler update.
@ivanpribec , upvoting the proposal will be a great start.
But what will be good for the Community will be to collectively start raising their awareness and conscience and start steering Fortran toward a more relevant state in computing.
The resistance to implicit none not being made the default appear based on all kinds of non-technical reasons: “let the sleeping dogs lie”, zero-sum game mindset, or crab-in-a-bucket mentality, etc. This is extremely detrimental for Fortran.
Challenge the status quo, develop a vision for the language standard, rise above the limited thinking of commercial vendors with their smaller and smaller budgets for Fortran, and work toward crowd-funded solutions is what the Community can do for itself in their practice of Fortran. @certik and LFortran leads the way on this.
But if not, not aiding and abetting in any way all the questionable specious and circular arguments against a change requiring minimal effort and one that seeks to minimize adverse impact while maximizing benefits and that is decades away will be useful.
I missed this claim. It (dynamic variables going out of scope) may not have been standard conforming (no one used the standard before F77), but still to today, pre F77 code that assumed variables were static have been the downfall of using much legacy code, especially for those new to Fortran. It has had a huge effect on the perceived reliable use of legacy codes, especially when new users do not know the detail of the original analysis. The solution was (not simple but) clear; set the required variables as save.
Similarly the present dilemma with changing to “IMPLICIT NONE” has a (not simple but) clear solution; declare all variables.
I think this change to the standard would be a good thing, as long as compilers provided an option -fimplicit-default for legacy codes.
This change would be a good change for the few who don’t use it already, by suggesting this is a good programming style. It would not be a hidden change ! as many errors would be reported. It could actually help to identify some bugs that have previously been hidden.
1 Like
Yes exactly! It will fix more bugs than it causes. And the command line flag is there for the people who refuse to make trivial changes to legacy code. There is absolutely no downside.
Note the -warn errors thing is not ideal. That turns ALL warnings into errors right? I don’t want that.
I don’t believe making the people who want to write good modern code have to jump through these kinds of hoops is a good thing. Make the people who want to write code like it’s 1977 have to do that.
@JohnCampbell , unfortunately “declare all variables” will not catch the IO (oh) → I0 (zero) typo errors that have plagued Fortran for decades without something like IMPLICIT NONE in place. In my experience it’s those type errors that are the most common (at least with inexperienced (and some experienced) programmers). Also one thing that has always puzzled me about the whole “can’t refactor because of recertification cost” debate is what kind of a certification process would actually allow implicit typing.
That’s a common problem with compiler options – they may interact in unforeseen ways, or reach too far.
Adding declarations to old code can also be troublesome. The old code may already contain a few explicit type declarations, and the newly added declarations should not duplicate those existing declarations. If the old code contains common and equivalence, adding correct declarations will require that some good tools be available for doing so without introducing new errors.
The question really is why any such issues need to hold back a move toward an explicit declarations state that is only beneficial.
These problems need not be a permanent handicap, not after ~45 years since the advent of implicit none and additional 10-20 years for the change to be standardized in reality.
I’d love to stop having to put implicit none everywhere, but the conserns over backward compatibility is a real problem that needs to be taken seriously.
In the meantime maybe fortls could by default complain loudly about blocks missing implicit none? Although not as good as complete elimination I think that would be a helpful way of guiding newcomers towards writing modern Fortran. Not sure how feasible it is to implement though, @gnikit?