I’m glad your organization implements such scrutinizing review and maintenance workflows. Sadly, I don’t think everyone can afford those.
If you’re talking about the reaction it’s a “scene of FORTRAN 66 horrors”, this is just a form of chronocentrism. At the time it was written, the routine may as well have been a programming marvel.
Functions and code sections which get refactored frequently are called “hotspots”. According to works of Adam Tornhill on software evolution these hotspots correlate with defect dense parts. If a code doesn’t get revised it may as well mean the code works.
Of course today it would be unreasonable to expect young programmers to learn F66, just so they could fight their way through NASTRAN. Ultimately this boils down to short-sightedness (also a form of chronocentrism) from the NASTRAN developer teams. Amusingly, MacNeal-Schwendler (now Hexagon AB), the company that commercialized NASTRAN, had an estimated revenue of $230 million USD in 2016. Hexagon AB had a revenue of 4.3 billion € in 2021. I’d be curious to know how much (if any) of these funds ever trickle their way down into Fortran compiler and tool support?
Ansys, another large user of Fortran according to some sources, has a revenue of 1.91 billion US $. It’s a mystery to me how come these and other big companies don’t engage more actively with the Fortran programming language community, unless it all happens covertly via vendors and representatives in the Fortran committees?
It’s much simpler to add -fimplicit-none or equivalent to your build configuration and be done with it. It’s annoying, but it’s a small one-time annoyance.
If you do try to automatically add implicit none statements, you have to include interface blocks (as @FortranFan mentioned) but you don’t have to do subprograms in modules and submodules.
Just for confirmation, does Intel Fortran (ifort) have some option that corresponds to -fimplicit-none? The old thread in the Intel forum below suggests there was none at that time, but I am not sure about the recent ifort versions…
Edit: Sorry, the reply just below suggests there is none even now.
I’m perfectly aware of the issues with adding implicit none to existing codes. Even though I mentioned modules my main focus is on legacy Fortran (fixed format .f files).
Adding -fimplicit-none or -u might work for gfortran or NAG but I don’t think there is an equivalent flag for Intel Ifort. You can force ifort to give you warnings but only in combination with -warn. I rarely use gfortran and have only used NAG once a long time ago. The issue is not that there exists compiler flags to turn on implicit none, the issue is the polarity of those flags should be reversed. If you tried to get me to use (let alone buy) any code that still used implicit typeing I would tell you to take a hike. It’s dangerous, it has been demonstrated for countless decades to be one of the major sources of bugs in Fortran code, and it is universally accepted as both poor software engineering and lets be honest, lazy programming.
Intel Fortran, like Compaq and DEC Fortran for decades, definitely has such an option. It is called -warn declarations, and requires all entities to be explicitly typed, otherwise you get a warning. There is a separate option that turns warnings into errors.
Fortran has NEVER deleted a feature without making it obsolescent for at least one revision - we’re not going to start now. I have been lobbying to make implicit typing obsolescent, and think this has a good chance of happening, just as was done for COMMON, EQUIVALENCE and fixed-form source. Over time, this will accomplish what some folk here want, reducing the use of implicit typing in new or revised codes.
Thanks very much for the additional info! However…, as far as I understand from the linked thread above, -warn declarations does not correspond to -fimplicit-none, and so the OP (in that thread) wishes the latter? Or possibly, is there a way to selectively turn -warn declarations only to an error (without affecting other warning options)?
I think it would be useful if an exact counterpart to -fimplicit-none is available in all the major compilers (particularly Intel Fortran), but if not, the “use -u” argument linked above (https://j3-fortran.org/doc/year/22/22-182.txt) does not seem to make sense (to me).
Thanks, Steve. I can live with making implicit none obsolete for now. One question though. Any chance of eliminating some of the annoying requirements such as the placement of implicit none after USE I mentioned up thread along with the need for IMPORT in interfaces. I still don’t understand why thats needed but would appreciate an explaination if you have one. I think its due to how the concept of scoping units are handled in existing compilers but that is just a guess.
Offhand, I don’t know what prompted that requirement nor what might break if it was relaxed. Is it really a problem?
As for the need for IMPORT in interfaces, this happened before my time on the committee, but we did talk about it at last week’s meeting, and I was told that there was a heated discussion on the topic of whether host association works inside of an interface body back in the Fortran 90 days. The view that won was that an interface body was a “window” into the external procedure, and that the body should replicate the declarations in the external procedure. IMPORT was added later to make it easier - I wrote a lot about this in Domestic or Imported? - Doctor Fortran (stevelionel.com)
Interestingly, the reason this topic resurfaced was that the new generic template feature being designed DOES do host association in its interface blocks, for good reasons.
Admittedly it portends well for Fortran to read this.
However I just don’t see how it is possible to “make implicit typing obsolescent” without eliminating implicit mapping.
Say implicit typing is made obsolescent in a Fortran revision 2XYZ. Immediately the use of implicit none becomes obsolescent that a conforming processor then will try to detect and report as far as it can do so by reference to any of numbered rules and constraints. However the implicit mapping may or may not be obsolescent; it will depend on the rest of the semantics:
say implicit mapping remains: the obsolescence of implicit none then will make matters absolutely worse.
But now if implicit mapping is too made obsolescent, then one needs something in its place that is not obsolescent, some another semantics to dictate the mapping. One simply cannot make something obsolescent without a replacement facility.
But then the replacement to the implicit mapping is exactly what is proposed in the original post, "If a mapping is not specified for a letter, the default for a program unit or an interface body shall be NULL, and the default for a BLOCK construct, internal subprogram, or module subprogram is the mapping in the host scoping unit"
So I think there is a real catch-22 here, I do not think implicit typing can be made obsolescent first.
The real need is for implicit mapping to be tackled first and that is what this proposal is all about. Once this is done, then implicit typing can be made obsolescent. And if better counsel prevails with Fortran, implicit typing can be deleted too in a future revision!
There are situations that call for *exceptions to the best of rules and procedures, however well intended and comprehensive. The case with implicit mapping is one such exception, I am presently convinced.
Either make that exception, or get into rather knotty situations that then force the status quo with implicit typing.
Ok, so let me get this straight. First you guys want to eliminate the default implicit typing that is the current standard. This will require people to add something like
implicit real(a-h,o-z), integer(i-n)
to all of the legacy codes that they use.
Then you want to eliminate implicit typing altogether. This would require those programmers who just added the implicit statements to go back into their legacy codes, remove the implicit statements and explicitly type all of the entities in their codes. And they would need to do this to all the legacy code they use that already had implicit statements in it too.
And I should point out, that this still does not solve the basic problem with legacy codes in the first place, namely that they already exist in books, on servers, and by individuals sharing the codes among themselves in their original forms. Those codes will then need to be changed, rather drastically I would say, in order to use them.
And you think this will be good for the language? Getting jerked around by the standards committee twice, within a relatively short time period (say one or two revisions)? First requiring them to fiddle around with the legacy codes, then declaring that what was just required of them is now obsolete and they must undo what they did and do something else even more drastic. How can that kind of plan possibly be good for the language?
If this questionable plan is enacted, should the standards committee also provide tools to the programmers to make these changes automatically? By the nature of legacy codes, this is not something that will be done once to a given code, it will need to be done by each programmer every time the original code is accessed, from now to eternity. Every time the original code is typed in from a book, or downloaded from some server somewhere, or sent from one person to another by email, this code transformation will be required.
I’m not sure where this is coming from. If implicit mapping is obsolescent, then that includes IMPLICIT other than IMPLICIT NONE. Compilers would be required to have the ability to diagnose uses of variables or functions whose type was not explicitly declared, as well as uses of the IMPLICIT statement that supplied mapping to initial letters.
I agree it would make no sense to do this and still allow the IMPLICIT statement to specify mapping.
Designating something obsolescent can be done for two reasons:
(1) warn that the feature may be deleted in a later standard
(2) express the view of the committee that a feature should not be used
I think it’s fine to say that implicit typing, as exemplified by code such as
implicit real(a-h,o-z), integer(i-n)
is obsolescent for reason (2) above, but as others have said, actually removing it would be too disruptive. Maybe features satisfying (2) but not (1) (they are bad but will remain in Fortran) can be designated deplorable . More seriously, if the committee did make implicit typing obsolescent, perhaps it could say that it does not expect to remove it in the future (although one committee cannot bind the hands of a future one).
. More seriously, if the committee did make implicit typing obsolescent, perhaps it could say that it does not expect to remove it in the future (although one committee cannot bind the hands of a future one).