Eliminate implicit mapping

Help
47

In order to move forward, I propose we let this discussion rest until fpm can by default enable “implicit none” and we get some experience using it. To that goal, please help us finish Draft: initial implementation of implicit_none by certik · Pull Request #506 · fortran-lang/fpm · GitHub. @jacobwilliams, @FortranFan, @everythingfunctional and others who want this feature, if anyone (ore more!) of you can help, we would really appreciate it.

After this is implemented in fpm, let’s revisit this discussion what the next steps should or could be!

1 Like
49

A bump to this suggestion entirely in reaction to a Dr Fortran blog post, “Implicit Dissent”

It will be better, I feel rather strongly and so I repeat, if the practitioners of Fortran and the standard bearers make attempts to distinguish between

  1. implicit typing and
  2. implicit mapping.

That is, to let implicit typing refer to the facility achieved by explicit IMPLICT statements in code such as IMPLICIT INTEGER(I-N), DOUBLE PRECISION(A-H,O-Z)' that are common in legacy FORTRAN codes based on FORTRAN 77 and its various extensions. Or in modern Fortran codes, the ubiquitous implicit none statement.

But for implicit mapping, again note it refers to the specific mapping scheme in the Fortran standard, “If a mapping is not specified for a letter, the default for a program unit or an interface body is default integer if the letter is I, J, …, or N and default real otherwise” that has been rather detrimental to both the practitioners and to the overall goodwill toward Fortran to remain as “lingua franca” in scientific and technical computing.

There is really no need for Fortran to even obsolesce, let alone delete implicit typing as distinguished in the 2 paragraphs above. If anything, under particular circumstances and as Fortran might advance to interactive computing, implicit typing via explicit IMPLICIT statements can even be accepted as a good coding practice (GCP). The important point though is that its use is really a CHOICE for the Fortran programmer.

Implicit mapping on the other hand must go. It FORCES a modern Fortran practitioner to introduce implicit none statement in each and every program unit as well as all the interface bodies. See the example in the original post re: the latter.

There is no choice in practice really, the implicit none statement has to be typed AD INFINITUM.
And note since MIL-STD-1753 starting 1980 i.e., over 40 years ago, almost every major institution such as NASA and US national labs, etc. and all the major and small companies and university and research departments developing Fortran libraries and applications have sought escape from the ill-effects of implicit mapping in one form or other in their codes.

The situation now is there is hardly any code in Fortran known to the public domain that consciously seeks to employ the implicit mapping facility in the standard. But yet the typing of implicit none is continued to be imposed on coders.

So again, I keep hoping against hope the readers distinguish implicit mapping as entirely separate from the implicit typing that is achieved with explicit use of IMPLICIT statements in code.

However the blogposts such as above keep conflating the two which makes communication so much harder for those offering minority reports like me and which then truly hurts those seeking to bring a different perspective and a meaningful improvement to the language for another Community from industry who is away from forums like these and who are silent because their work demands don’t allow them to make their voices heard online but who are also often herded away Fortran by their management simply because Fortran advances way, way, way too slowly or not at all.

50

To be clear, in Eliminate implicit typing · Issue #90 · j3-fortran/fortran_proposals · GitHub when I say we should delete “implicit typing”, I’m talking about what you are calling “implicit mapping” here. I don’t propose that the implicit statements be removed, I don’t think that is a good idea (what you call “implicit typing”). implicit none should be the default, and any variable not explicitly declared should be a syntax error. If you want to use implicit double precision... then that’s fine too… but it’s not forced on a new user like implicit none is now.

51

My two cents: I’m pretty new to Fortran (as of a few months ago) and I will admit, I’m on the side of making implicit none the default behavior because the reason I moved away from python was mainly due to assumed types screwing with me :slight_smile:

6 Likes
52

@adenchfi awesome. I agree. If you have time, please help us move this forward: Draft: initial implementation of implicit_none by certik · Pull Request #506 · fortran-lang/fpm · GitHub.

53

@certik, you may have surmised this, but allow me to clarify for everyone … for whom the advancement to Fortran I hope to bring, all that matters is the Fortran standard.

As long as that line, “If a mapping is not specified for a letter, the default for a program unit or an interface body is default integer if the letter is I, J, …, or N and default real otherwise,” remains in the standard, the other efforts such as what you propose now with fpm are noteworthy but ultimately of little to no significance to many in industry.

Meaning Fortran is sitting on a 40+ year history where coders have been forced to introduce implicit none in every program unit and interface body and nothing that is done outside of the standard will permit any manager or technical lead to accept any code in production toward a program unit that does not include implicit none. It will be much, much easier for powers-that-be to accept code in production written in any number of other languages widely used ahead of Fortran such as C++, C#, C, Python, Julia, Rust, Visual Basic, Java, etc. but not Fortran code without implicit none - think about that for a minute.

40+ years since implicit none appeared in MIL-STD-1973 for FORTRAN, the next advancement we seek is the enhancement to the standard.

When it comes to standardizing standard practices that has to be the first goal of a standard, the standard comes to either mean something, or it doesn’t. There is no in-between here.

My focus at this stage is thus the standard. Everything else will readily fall in place if the standard advances.

1 Like
54

To be fair, it’s really only modules, programs, and interfaces, not every unit. Granted, if procedures are defined outside of modules or programs, they need it too, but I don’t think this is common for new code nowadays.

I agree it’s important to distinguish between implicit typing and implicit mapping.

I personally never felt forced to type implicit none. It’s possible–and I do it often in toy programs–to omit implicit none and not use implicit mapping. To me it’s like a seatbelt in my car–nobody’s forcing me to use it, but I prefer to use it than to get hurt or to get a ticket.

2 Likes
55

I think that the standard should standardize an already existing wide practice. Currently, the existing wide practice is to ensure every module, program and interface uses implicit none. And the standard implicitly “recommends” exactly this practice. So there is no discrepancy.

My goal is to first change this practice, ensure our tooling (fpm, compilers, documentation, tutorials, …) allows and recommends to omit “implicit none” and it would still be enforced. We are not there yet, so I am no worried about the standard.

Once we get there, then it would be a good time to also standardize this new practice.

2 Likes
56

Entirely unsurprisingly to me yet most disappointingly, I listened to a thundering “no” on this today that was delivered rather softly!
https://j3-fortran.org/doc/year/22/22-182.txt

57

But the arguments are always the same: Changing this breaks old code, which is clearly not a future-oriented view but rather a concession for those who don’t dare to touch their legacy cruft.

Maybe we can get a different opinion. Everyone who thinks that implicit typing helps to write readable and maintainable code and is the unique feature why you prefer Fortran over other language: Please respond here!

1 Like
58

I think the real driving force behind this is summed up in the line in 22-182.txt that reads

“Doing this would drive away existing customers”

I don’t see “customers” in this case being a generic term for Fortran users but actual paying customers. So all of us who want to move the language forward are at the mercy of a small but vocal (and I must say from the tone of the comments in 22-182 condescending) group that want to put their own commercial interests over what a large segment of the user community think is a needed and long overdue change to Fortran.

4 Likes
59

It is not “don’t dare to touch” as much as callous indifference on the part of an influential some and a sheer failure of imagination by the collective to arrive at any options toward a better path forward. Status quo, or “go away, will ya?” attitude.

“Explicit is better than implicit” may be part of The Zen of Python and recognized by others when it comes to programming generally but when rubber meets the road with continued use of FORTRAN and how it affects Fortran, a critical few practitioners - based on accounts of certain vendors - may be willing to make changes to their code or build-chain toolsets, however slowly, for any number of purposes but they simply cannot do away with their supposed reliance of implicit typing, however limiting it might be.

IMPLICIT INTEGER(I-N) most likely but IMPLICIT INTEGER(I-N), REAL(A-H,O-Z) really, will inoculate these practitioners, whoever they are, from posterity and for which they will have \ge 10 years to adapt, but none of these matters to them - let everyone else do implicit none. The most unfortunate part for me is I, as a taxpayer, am likely among their paymasters because the chances are high the codebases and the practitioners in question are all among the taxpayer funded institutions that are likely insulated from external influence.

To borrow a powerful refrain uttered by a superb actor in a movie, “I have been around, ya know”!! I too have evaluated and refactored quite a few codebases in industry that originated in the 1960s thru’ 1970s and arrived at peak development during the 1980s: each and every one of them either had IMPLICIT NONE or IMPLICIT INTEGER(I-N), DOUBLE PRECISION(A-H,O-Z) that was included in the Fortran program units forcefully as a matter of good practice. None of these codebases would be impacted by the proposed enhancement here.

Yet here we are: do implicit none, or migrate away! type “-u” as indicated in the above paper, or f u!

2 Likes
60

Yes, it seems that a lot of customers of Fortran compilers have a very old code base.

I’m an ocansional user of a commercial finite element code, most likely written in Fortran. Of course, I can’t see the actual core code. But some helper scripts are written in bash. I think every intern that has ever worked in this company was invited to contribute his first ever written code to this script :grinning:. Honestly, I would fail students for delivering such a mess. I fear that the actual simulation code is of the same quality.

61

You and I are likely footing the bill for these “customers”.

62

In the “commercial” space, in all other aspects, “breaking changes” do indeed come with the territory, all the time! It is intended and implemented, however unwelcome. Commerce will cease otherwise.

63

Blockquote
IMPLICIT INTEGER(I-N) most likely but IMPLICIT INTEGER(I-N), REAL(A-H,O-Z) really, will inoculate these practitioners, whoever they are, from posterity and for which they will have ≥ 10 years to adapt, but none of these matters to them - let everyone else do implicit none.

Given that the default of implicit typing will remain part of the standard, what would you advise those who are 1. new to Fortran, 2. writing new code, that does not involve usage of implicit none? Is there a switch in gfortran that will warn or signal an error on the use of implicit typing? Maybe instead of removing implicit typing, perhaps its use should be a warning?

64

The switch is there at least since version 4 and has been mentioned here many times:

-fimplicit-none
Specify that no implicit typing is allowed, unless overridden by explicit IMPLICIT statements. This is the equivalent of adding implicit none to the start of every procedure.

Edit: It has occurred to me that using this switch is actually not equivalent to adding implicit none, as the latter does not allow adding any explicit implicit statements afterwards.

1 Like
65

Thanks. I was grepping under the W- options on this page, not the f- ones:

66

C++ has incorporated so many new features since C++ 11, but people are still unhappy. Google has started an experimental successor to C++:

1 Like
67

Re: “what would you advise …”,

  1. Don’t pay attention to my advice!

By the way, with Intel compiler(s), the compiler option will be -warn declarations which does indeed generate a warning rather than an error i.e., unless one uses a separate compiler option which then turns compiler warnings generally into errors!

1 Like