It’s also funny that the author of the post didn’t mention the real(kind(0.d0)) thing. A profoundly weird and confusing bit of syntax.
Upvoted, of course. I have to admit I dislike github and I will never upload any code there - but I still use it for cases like this one.
Let’s just hope our grand-grand-children will see it being part of Fortran 210x, if not later. 
Thank you very much, appreciate it greatly. Or more likely all those Fortranners who pursue Fortran in the future will appreciate this simple, trivially low-cost change, at least for a language committee and vendors i.e., unless they make a mountain out of it and needlessly complicate matters well beyond a change to a sentence or two related to implicit mapping in current standard and making default certain compiler options!
I have been thinking on the implicit none problem lately. My original thought was yes, great idea. Then a change in another language to an “equivalent” feature broke a lot of my code developed in the last year. It was a pain to fix, and I very quickly decided that fundamental changes like implicit none, are a waste of time to fix as you break to much.
It is equivalent to the medical - do not harm. You achieve a minor satisfaction internally in fixing a moot point and you cause cardiac arrest to legacy Fortran.
We have more important Fortran problems to solve than a minor bug in some one’s ear.
2 Likes
i don’t fully understand your argument. Making implicit none the default doesn’t break anything. If you have old code that was using this feature, you have to use a compiler flag to get it back. Nothing changes. People can still run their FORTRAN 77 just fine. It just means that this horrible feature isn’t shoved in the face of every new user. If they forget to declare a variable, they get a syntax error that tells them their mistake. Easy peasy. It fixes more bugs than it causes.
2 Likes
And the weirdest of weird statements is that the implicit typing was meant to… save space, make file sizes smaller.
If I take Harrison’s structural analysis program from 1973, and put it into a compiler that assumes implicit none, it should not compile, it has no declared variables. So why is that not a problem?
Why Harrison, a lot of modern SA packages rely on the methods he laid out.
Then the compilers provide an option to re-enable implicit typing. You would use that. I don’t see this as a major burden.
Otherwise, you have to update the code (add implicit double precision or whatever the original code was assuming).
I agree, but it is much more than just changing implicit none, the compilers need extra switches - adding the switches changes the proposition, IMHO it is not worth the effort, but I am happy to use whatever free compiler Intel Fortran gives me.
It is akin to asking why do we call a bear a bear, because some human, who could not conceive of Fortran, as their group was on the Russian steppes 10,000 years ago, called it a bear and to this day in all Indo-European languages there is a bear word that can be traced to some human probably running for their life. Fortran will be here forever, it is to entrenched and useful.
ísbjörn = Icelandic for bear.
The issue with implicit none not being the default is not “a minor bug in some one’s ear”. There has been tremendous cost associated with it, countless hours of valuable time of scientists and engineers, etc. have been lost due to the issues that arise when the statement is inadvertently omitted.
Please see this thread: For whom Fortran? For what? - #20 by FortranFan
And note the several group situations where Fortran gets practiced. Again and again, the matters with Fortran come down to “For whom Fortran”? The deterrence implied by @macneacail 's comment - one that goes beyond a silence to not support the suggestion I linked upthread - is most unfortunate, it tries to influence based on certain groups e.g., (3) involving one-person or small team in certain domain (say academia) above others, say, group (2) and (4) where a default implicit none will be highly valuable.
I have taken great care to suggest something that is really low, low cost but which has great benefits whilst providing backwards compatibility to most codebases. For example,
- those who like
implicit nonein every program-unit / module can continue doing so - no impact to them - those who like
implicit integer(..), ..statements of the yore can continue using them - no impact to them either.
Comments by the likes of @macneacail such as “We have more important Fortran problems to solve” - as though the mere suggestion to make implicit none the default somehow prevents others from solving other problems in Fortran is so pretentious and distorted and which then overlooks the broader picture and the needs with the bigger tent approach are more reflective of the crabs-in-a-barrel syndrome that appears to afflict Fortran acutely which then feeds somewhat into the kinds of blogs in the original post.
2 Likes
But does that really requires a change in Fortran stardard?
Isn’t just about having -Wimplicit as a default compiler option?
Having it as a warning rather than an error is actually more consistent with the fact that Fortran does allow that.
For a quick test implicit typing can actually be handy. For larger code bases the development and production compiler flags are always carefully selected anyway.
That’s exactly what a compiler I used years ago did; it assumed F-standard (and therefore implied implicit none) unless the code was compiled with a “legacy” flag (in that case everything was treated as in the old times, and no old code broke.)
1 Like
Harrison’s program(s), from what I recall, used features that are not supported by non-IBM based processors such as $FILE statements to redefine the Fortran files. Thus the expectation one can grab code from 50 years ago that was developed with a given vendor system in mind and it must be made to run with no change is not possible to begin with and to base that as an immutable condition for the future direction of the language is beyond absurd.
3 Likes
It then defeats the purpose of the standard with something so basic with different processors having different options and settings and having to manage all that in one’s build chain toolsets.
Why not those who wish for “implicit typing” in a quick test be generous and be willing to add a statement themselves instead of forcing everyone else to include the IMPLICIT NONE statement in all modules and every definition in an INTERFACE body?
A single statement
implicit integer(i-n), real(a-h,o-z)
will allow anyone and everyone to achieve the current implicit mapping.
Anyways, all such excursions in discussions overlook the higher purpose that a modern Fortran aspiring to be type-safe must move beyond implicit mapping. It simply conveys the wrong impression to anyone coming fresh to Fortran, the reaction in the blog in the original post is nothing new. Instead of “you had me at hello”, many are lost during the first look itself at Fortran which is where implicit none typically is introduced.
3 Likes
I second that. Introducing Fortran 90 to new students, and having to explain in the very first session why implicit none has to always be there is just misleading for them. Some of them are already biased against “Olde Fortran” due to the hype other languages have, and they think implicit none is just a proof they are “right”. Others have no idea and their first impression is usually negative, since they have to hear about a relic of the past right away. The reaction in the blog above is indeed nothing new. I have seen it plenty of times. Students will realize the beauty of modern Fortran later on, but the first impression has to be… implicit none.
5 Likes
I’m also tired of trying to explain why implicit none is needed to students who have no programming experience beyond MATLAB or are somewhat fluent in another language. Also, although its more cosmetic than something that has the global effect of implicit none, I would also make prefixing CALL to a subroutine invocation optional for the cases where there is an explicit interface visible or specified in an external statement. After, “why implicit none”, “why do I need CALL” is the second most asked Fortran question I get.
1 Like
Is that somehow inaccurate?
I can certainly see an advantage of implicit typing if I’d be writing my program by hand on a sheet of paper to be passed on to a keypunch operator. Besides saving myself writing, it also saves typing for the keypunch operator. I would probably keep a list of variables and their meaning on a sheet of paper, placed on the side. Today MATLAB calls this the “workspace”.
If you look at the IBM 1130 page on Wikipedia, it states
Much user programming is done in Fortran. The 1130 Fortran compiler can run on a machine with only 4,096 words of core—though the compiled program might not fit on such a machine. In this multi-pass compiler, each “phase” processes the entire source program and takes it another step toward machine code. For example, the first phase reads the source statements into memory, discards comment lines, removes spaces except in text literals, concatenates continuation lines and identifies labels. The compiler is available in a disk-resident version as well as on 8-channel punched paper tape or punched cards.
4096 words - thats’s 4 KB (assuming 1 word = 1 byte). The fpm tarball is 149 KB, we could run it through FixedFormForever and see how much it shrinks.
2 Likes
If you read the Wikipedia article you lined to you will find that the 1130 has 16 bit words.
Note that the original C++ and Fortran programs explicitly uses double types and here I see real types which is not a fair comparison.
1 Like
@FortranFan using intemperate language does not prove your point, it merely gets people’s backs up.
-
I write a lot of code, very occasionally I will leave out an implicit none, it is annoying, but it is rare and it is easy to spot, it is at the top of the code in each functional unit. if it is a big problem for others, then make that observation.
-
Harrison was written in 1973, yes it uses the file system for the Sydney University system and yes you need to amend that to get the code running on systems that were not invented in 1968 when the code was written, a five minute exercise. I am not interested in the Fortran for the file, I am interested in the structural code.
Harrison’s structural code is still beyond that which can be analyzed in all beam theory Structural Analysis packages and this causes deep pain in doing frequency matching for real structures, I do that every day. Even the German Petersen paper and the implementation in the German SA package is flawed. The problem is Harrison is 2D and you need 3D, but at least that algorithm exists in one paper, but the authors coded it and threw away the code, but provided enough answers you could check it.
- I am not trying to influence anyone, I am offering an opinion. I really do not care about any of these theoretical things, I will use for the rest of my life, what Intel gives me and I will be happy.