Implicit typing and backwards compatibility

[RonShepard]

Regarding implicit SAVE,

@msz59

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.

You have a good point about the program unit, where the concept of SAVE is redundant. This situation already occurred in f77 with COMMON blocks. Common blocks in the main program did not need to be saved, while those appearing at other places where they could go out of scope did require a save statement (at least in some cases, it was a complicated issue). SAVE was introduced in f77. Before that, everything, common blocks and local variables, basically either had save semantics or their status was undefined by the language. SAVE was introduced to clarify the differences.

However, as you say, consistency with the rest of the language should probably be the determining factor. It would be simpler for both compiler writers and programmers to know just one simple rule, rather than to separate off some of the redundant cases.

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

I don’t think I’m in favor of UNSAVE or NOSAVE or any of that. That is all extra baggage for compiler writers to support and for programmers to understand. It is just a complicated way to do something that is already clear and straightforward in the language, namely a simple executable statement.

par = 23

Also, as a matter of style, it is often better to have such initializations in the code as executable statements rather than in the declaration statement. Consider the computation of, say, a summation over elements.

real, nosave :: sum=0.0
do i = 1, n
   sum = sum + something
enddo

In that case, everything is visible and it is clear what is supposed to happen. But what if there are a few dozen lines of code in between. Then you have to scroll back to see if it was initialized, and what it was initialized too. But if the initialization is done as an executable statement right there, then everything you need to know is localized.

sum=0.0
do i = 1, n
   sum = sum + something
enddo

That first way is not always best, even if NOSAVE were available. And of course, in current fortran where there is no NOSAVE attribute, that first way is almost certainly an error because of implicit save.

[FortranFan]

@RonShepard

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.

I really fail to understand the point of the argument here. Anyways, codebases such as OASES and NASTRAN likely never conformed to any Fortran standard revision given the evidence thus far with argument rank mismatch violations. Besides, they fail to conform to the current standard on count of other violations starting with the deleted arithmetic IF statement too but other removed features.

As such, these nonconforming codes are mere distractions to the discourse.

[FortranFan]

The bigger picture to me is the appeal to a vision for Fortran in the next decade: a simple aspect that can be a part of this is as follows:

• Circa 203X, the Fortran standard shall eliminate implicit mapping semantics.
• My understanding is this will be a breaking change, but so be it.
• I believe the benefits of this change are tremendous, potentially unlimited. Whereas the costs are relatively low.

In fact, for nonconformant processors such as gfortran, the cost can even be even lower tending toward zero when it comes to the change to eliminate implicit mapping i.e., they can simply do nothing or make minimal adjustments.

Coders can then go with newer, modern processors which may, off the bat, make implicit none the default: LFortran appears to lead along such lines.

But with the work domains of interest to me, I need the ISO IEC standard to include the change, hence my appeal to include this in Fortran 202Y standard revision.

The users will have 5+ (perhaps even 10 or more!) additional years to adapt to the change which is coming on top of nearly 5 decades of implicit none being recommended to overcome the implicit mapping in Fortran.

I believe this is more than adequate lead time to adapt to the change.

Hence please support this simple element with elimination of implicit mapping in the language.

[certik]

@RonShepard

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.

Note that this is already the case if an inexperienced programmer takes implicit typed code and pastes it inside a module that contains “implicit none” at the top. It will not compile.

Also note that I already have to put special compiler options for older code, e.g., here: https://github.com/certik/hfsolver/blob/b4c50c1979fb7e468b1852b144ba756f5a51788d/src/ffte/CMakeLists.txt#L16, where I had to put -std=legacy, otherwise the older code would not compile together with more modern code.

So if, for example, GFortran keeps implicit typing on for -std=legacy, then nothing would break, at least for the above code. For code from netlib, just keep using -std=legacy and there will be no problem.

If you decide it is time to modernize the old code, then just put “implicit real …” in the code, and a few other changes, and you can then mix and match it with modern code, and then gradually modernize it.

[FortranFan]

@certik

If you decide it is time to modernize the old code, then just put “implicit real …” in the code, and a few other changes, and you can then mix and match it with modern code, and then gradually modernize it.

+1

Also kudos to @jacobwilliams . NASTRAN was mentioned upthread. @jacobwilliams has a great blog post about a subprogram from NASTRAN with details on refactoring the procedures and all the enhancements implemented toward such modernization:
https://degenerateconic.com/binary-search.html

Note the deleted arithmetic IF statement in use by the original BISLOC subroutine in NASTRAN - standard conforming processor today can stop compiling the code as is. The subroutine also has other obsolescent features. Elimination of implicit mapping can only help improve the situation with such code.

Anyways, it must be so obvious to @jacobwilliams as to not spike out the change to implicit none in the blog!! The community can now really do with implicit none being the default, at least 10 years from now if not this very minute!

[RonShepard]

@FortranFan

I really fail to understand the point of the argument here. Anyways, codebases such as OASES and NASTRAN likely never conformed to any Fortran standard revision given the evidence thus far with argument rank mismatch violations.

Older fortran codes typically never conformed to any standard because the older standards were too limited. If you wanted to do anything nontrivial, you needed to go outside of the standard, for memory allocation, or date and time information, and on and on. That has nothing to do with the idea of introducing a change in the language standard that is incompatible with 60+ years of legacy code.

Just out of curiosity, I looked through my old copy of Applied Numerical Methods by Carnahan, Luther, and Wilkes. This was a standard textbook and reference book in the 1970s, and all of their code examples are in fortran. Every program in that book uses implicit typing, and many of them use just the default typing rules with no IMPLICIT statement at all. Of course, there have been newer textbooks since then, but this is an example of the type of legacy code I was talking about.

[edit] I also looked in Introduction to Numerical Methods by P. A. Stark. I actually took a course that used this book. Again, all of the code examples are in fortran, and they all use implicit typing with no IMPLICIT statements. These examples do use quoted strings in format statements, which was an extension at that time, but otherwise they are mostly standard f66 code. The first chapter is about integer and floating point arithmetic, relative and absolute error, and roundoff errors. That is, it is talking about numeric types. Numerical programming requires that knowledge.

[ivanpribec]

@RonShepard

This was a standard textbook and reference book in the 1970s

Lots of such books have probably been thrown away by libraries. I have bought several second-hand textbooks on numerical methods and Fortran, and they are all ex-library books from USA and UK university libraries. My father was a librarian and for his master’s he did some statistics on when is the right time to throw medical journals away or move them to an archive, in order to save shelf space given the falling number of loans.

[FortranFan]

@RonShepard

Older fortran codes typically never conformed to any standard because the older standards were to limited. …

So again, let the state of Fortran be the following circa 203X:

Instead of telling posterity to insert implicit none in all relevant program units and interface bodies …

… if and when one finds those old hardcopy books and extracts the code somehow and sends it to a Fortran processor, insert a line suitably in the program:

       IMPLICIT INTEGER(I-N), REAL(A-H,O-Z)

[RonShepard]

@FortranFan

Instead of telling posterity to insert implicit none in all relevant program units and interface bodies

I’m not telling posterity to do that. It is up to them to do that if they want. If they want to use implicit typing, it is up to them. Those who want to change the standard are the ones trying to impose their ideas of good programming practices on posterity.

Look, I use implicit none all the time. I even used it as an extension before it became legal with f90. So I’m already convinced it is a good programming practice. But I’m not trying to force all future programmers to do that, and especially not at the expense of making 60+ years of legacy code incompatible with future standards. Some programmers don’t like to type data declarations, they want to take the defaults and start programming their algorithm. That is fine with me for them to do that, now and in the future.

The point of my post was to show the potential problems that would arise if the default typing rules are changed in a way that results in incompatible legacy code.

… if and when one finds those old hardcopy books and extracts the code somehow and sends it to a Fortran processor, insert a line suitably in the program:

       IMPLICIT INTEGER(I-N), REAL(A-H,O-Z)

I am an experienced fortran programmer, so I know how to fix the code. We are now talking about inexperienced programmers who do not understand fortran, or maybe even those who do not understand data types and kinds. Incompatible changes to the standard will be a barrier for these types of programmers, and I think that will have a detrimental affect on the future popularity of the language.

[FortranFan]

@RonShepard

… Those who want to change the standard are the ones trying to impose their ideas of good programming practices on posterity. …

I disagree with everything in the whole comment.

Re: “Those who want to change the standard are the ones trying to impose their ideas of good programming practices on posterity,” it is patently inaccurate:

• the first imposition on programming comes directly from the standard itself with its implicit mapping. Let there be no doubt: the standard itself is first the root of the problem with its implicit mapping scheme with letters I-N and A-H, O-Z. The fraction of coders who would want the types to be default real only because their object names started with letters A-H or O-Z is so miniscule as to be statistically irrelevant. So a programmer is then forced to introduce an IMPLICIT statement in a program unit, practically there is no choice otherwise.

• the second imposition instead comes indirectly from comments such as the one I quote above because they feed into innate tendencies of any community which is “resistance to change” and “let sleeping dogs lie”, etc. aided by trumped up dangers that then make it so difficult to garner support for change given the plebiscite nature of getting features into Fortran.

Elimination of implicit mapping does not propose to remove IMPLICIT statements from the language and as such it offers a route for continued consumption of conformant old codes while also easing the semantics for new codes.

In the context of elimination of implicit mapping then, the repeatedly attempted alarms by the likes of @RonShepard such as “potential problems”, “barrier”, “detrimental affect on the future popularity” run counter to all the evidence I have seen and experience I have gained from working with Fortran, so I reject them entirely.

[FortranFan]

@jacobwilliams

… I don’t know if the committee would agree. Frankly I’m pessimistic based on recent history.

You’re right, it has long been clear the chances the standard committee will accept and vote to remove implicit mapping are nil.

There is just too much resistance to change on some aspects like implicit mapping but not so on others like arithmetic IF, ASSIGN statements, non-block DO construct, H edit descriptors, etc. that got deleted in earlier revisions even as codes such as OASES and NASTRAN and others used such features.

And as seen by the change with deferred-length allocatable character arguments issue with Fortran 202X where oddly no one on the voting committee cared even a bit that some code might “break” as a result, it is clear there is a willingness to deviate from the notion of backward compatibility when convenient.

But with implicit mapping proposal if at all it reaches the committee, my expectation is the backward compatibility argument will be wielded like a sledgehammer on it and that it will be killed faster than the NY minute.

It may take another 25 years or more before the standard can be finally be rid of implicit mapping.

But I personally would like to remain undeterred and keep on trying to eliminate implicit mapping and hope a generational change will eventually come to accept enough is enough.

[urbanjost]

With the intel compilers when you install it you can change the default options via a config file. One of the
options available on ifort(1) is -implicitnone (AKA -u or -warn declarations). You can also set your own personal default(s) in files.

So simply make a file called “ifortA.cfg” and set the environment variable IFORTCFG to the full pathname
of the file.

You can set up different sets of options and change your defaults so might have a debug set of options and one for optimized performance, or generating listings, profiling, etc.

So with ifort(1) if you own the directory where it is installed you can change the default. Might not solve it for a newbie unless someone else installed the compiler, but lets anyone experience what it would be like to have more modern defaults.

I do not know of an option to do this without adding an option to the command line or making a wrapper around you compiler with other compilers. Does anyone know of similar methods of changing the compiler defaults? You can also set an environment variable so if you have the module command on your machine it is easy to set one of the environment variable methods to change the defaults.

[Harper]

You wouldn’t have to provide just one line saying
IMPLICIT INTEGER(I-N), REAL(A-H,O-Z)
in an old program. I have seen and used old programs with a lot of external subroutines and functions, which was the only way to go before CONTAINS became part of the language, and you would have to put that IMPLICIT line in every one, except for those where REAL had to be replaced by DOUBLE PRECISION, and some also needed COMPLEX as well…

[certik]

Those old codes can simply be put into dedicated files and then you can compile those files with appropriate compiler options (ensuring implicit typing and other things). You will always be able to do that.

[milancurcic]

I think this is a question of fundamental values and beliefs that won’t be resolved with technical arguments.

[FortranFan]

@Harper

You wouldn’t have to provide just one line saying
IMPLICIT INTEGER(I-N), REAL(A-H,O-Z)
in an old program. I have seen and used old programs with a lot of external subroutines and functions, which was the only way to go before CONTAINS became part of the language, and you would have to put that IMPLICIT line in every one …

Agree it’s one line but in multiple program units and interface bodies, as applicable. What you are stating is the equivalent of the situation today where a programmer has to include “implicit none” in multiple places. Let anyone who wants to consume the legacy codes with Fortran 202Y and later processors have to worry about such IMPLICIT statements rather than forcing that on new codes.

@Harper

, except for those where REAL had to be replaced by DOUBLE PRECISION, and some also needed COMPLEX as well…

So again, the standard itself is at the root of the problem. The implicit mapping scheme does not really prove too useful as defined to quite a few coders because (A-H, O-Z) map to default real.

So let the standard be rid of implicit mapping, at least by a future date, say Fortran 202Y. And evolve the language toward explicit declarations by default or explicitly specified mapping if so chosen by the programmer.

[FortranFan]

@milancurcic

I think this is a question of fundamental values and beliefs that won’t be resolved with technical arguments.

Agree, such fundamental values and beliefs are often influenced by progressive leaders, often the creators themselves, who truly, wholly care about something and who strive to evolve the creation, who think beyond costs and look toward the benefits and beyond.

C++ has this with Stroutrsup, Miller, Dos Reis, Sutter, et al.; Python with von Rossum and co., etc.

Fortran on the other hand gets failed by the standard, its workflow, its cost considerations and an inconsistent notion of backward compatibility wielded to kill or suppress certain standardization proposals, no matter how low a cost, even if it enables the commonly adopted practice such as overriding the implicit mapping semantics toward type safety in one’s code. A true caring for the current and especially the future practitioners is in short supply.

[msz59]

@FortranFan

And as seen by the change with deferred-length allocatable character arguments issue with Fortran 202X

Could you please give some details explaining this issue?

[FortranFan]

@msz59

Could you please give some details explaining this issue?

See this thread:

Implicit typing and backwards compatibility

On evidence, one can concede the evolution of the Fortran language has erred more on the side of pragmatic progress rather than intransigence on the basis of an extreme ideological position on backward compatibility. And that is a good thing. I would like to appeal to the same sentiment moving forward and once and for all gift the future generation of programmers of Fortran with an evolved and truly modern Fortran language feature that has implicit none as the default in all program units and…

[urbanjost]

I do not see the “other” implicit typing issues addressed, such as the default precision of floating point constants. As “everyone knows” things like

doubleprecision :: PI=4*atan(1.0)

etc,etc,etc … that generate inadvertent errors that “IMPLICIT NONE” does not address. Some way to declare default type in constant expressions to be the highest precision supported (would probably break a few things with constants passed as arguments) ? I personally do not ever remember having a problem with implicit typing except with a line that went from 72 characters to 73 with a fixed-format code, where it would have caught the undefined variable; and found it very useful for a language that can have so many variable names in complex formulas. I used compilers that were good at flagging unused and uninitialized values so I think that caught the most useful function of “IMPLICIT NONE” (require the compiler to identify undeclared variables, which as a consequence finds misspelled variable names). If Fortran was interactive I know the first statement I would enter would probably be an IMPLICIT statement like the current default (except I would just flag I or I,J,K instead of the current I though N (IN(teger)); or maybe setting everything to a REAL or COMPLEX default! My main reason to want it be the default is that is seems to bother so many others and that in general I think the strictest checks should be the defaults.
But if the standard actually does get changed, float constants have caused me more problems than implicit typing.

How often has anyone found a TYPE error in old code they are modernizing that adding IMPLICIT NONE caught? Many languages do not require strict typing at all and do not seem to take much flack for it; or default to everything being a string or guess (perl-like) when to treat something numerically, etc. I think if the default had been everything is treated as REAL or that integers had to start with an @ character or strings had to start with $ (common in several languages) there would have been less issues with Fortran
s default. Until you learn to think of I-N being the first two letters of “INTEGER” and can rattle off the English alphabet reflexively it really seems a very arbitrary quirky choice.