I agree with ivanpribec here. When one looks at an hello world program in C, C++, C#, Java, Python and Fortran implicit none is not a big deal. Here are exmples of hello world in each of these languages.
C
#include <stdio.h>
int main()
{
printf("Hello world \n");
return(0);
}
C++
#include <iostream>
using namespace std;
int main()
{
cout << " Hello World " << endl;
return(0);
}
C#
using System;
class hello_world
{
static int Main()
{
Console.WriteLine("Hello World");
return 0;
}
}
Java
class hello_world
{
public static void main(String[] args)
{
System.out.println(" Hello world");
}
}
program hello_world
implicit none
print *,' Hello world'
end program
I’ve taught introductory courses
in all of these languages (I worked
in university computing services for over 25 years)
and the class based languages (Java and C#)
throw up the most questions.
Ostensibly they were taken seriously during ANSI FORTRAN 77 and later with MIL-STD 1753, both in 1978 in that they did not seek to remove implicit mapping due to backward compatibility.
The same 13 years later in 1991 with Fortran 90, then 6 years later with Fortran 95, another 7 years later with Fortran 2003, and on and on.
At some point, one can simply embrace the change and move forward.
How about standardizing a new file suffix (e.g. .fx or whatever) that enforces implicit none (and also no implicit save etc)? If the existing codes are extremely unlikely to use that suffix, only new codes written in those files benefit from new semantics. In lectures, it is possible to start Day 1 with such a suffix, with no need to explain implicit none (it can be explained in the Appendix for “reading old Fortran”).
The underlying idea is to elevate Fortran as an explicitly typed language by default.
A “hello world program” is not relevant to this, besides the notion with it is generally to introduce to a newcomer a programming language in a succinct manner and in that respect, you can simply go with
print *, "Hello World!"
end
and not bring up implicit none at all. It will be far better for Fortran that way.
No we can’t double down on yet another file format. That’s just going to create more confusion. We already have two. We only need one. We need to delete fixed-form from the standard. It’s time to move on.
The arguments will then not only become far more convoluted and circular, but also outside the standard that then defeats the purpose of the standard.
The standard knows no file suffixes.
Besides any objective accounting will prove to you the work for compilers on *UX and Windows (and macOS) to intrinsically recognize a new file suffix by default will be far more effort than removing implicit mapping (limited change with some text in the language with no pressure on any compilers to follow up at all, really - Fortran 2018 made recursive procedures the default, few compilers are going to oblige with this default anyway, users will have to do extra work to get standard behavior as shown above by Intel oneAPI compilers). Not to forget there are Fortran processors where there is no such thing as a file suffix e.g., IBM mainframes.
Bottom-line: The focus has to be to get the standard to lead and advance beyond implicit mapping. Everything else will eventually follow.
Sadly, I see no evidence that the standard committe is familiar with the old expression
“Lead, follow, or get out of the way”
Also, in keeping with another old expression that " A camel is a horse designed by a committee" we the user community keep begging for a horse but the committee keeps saying “No, what you really need is a camel. Trust us, we are the experts”
It is an interesting idea, a diagnostic followed by a CodeAction to add implicit none is definitely doable, but given that I have yet to implement implicit variables I might have to think on how to do this. (Also I need to redesign the diagnostics to be able to enable/disable individual diagnostics features instead of the all/nothing approach)
Eliminate implicit typing is #5 in terms of “thumbs up” on the j3-fortran/proposals site. I don’t think it is out of order to try and put together a formal proposal for consideration for the next standard.
When someone says “eliminate implicit typing” from the language, what does that mean? Does it really mean to eliminate the IMPLICIT statement entirely? Or does it mean to change the default from IMPLICIT REAL(A-H,O-Z) INTEGER(I-N) to something else, like IMPLICIT NONE?
I have never understood why people get so worked up about this issue. Some programmers do like to use IMPLICIT NONE, and they have been doing so since before f90 when it was only a compiler extension and not part of the standard language. Other programmers like to use implicit typing rules, default or not, for a surprising number of reasons. In a language like fortran where variables are typed, there must be some kind of default, and whatever it is, programmers, new and old, must account for it. It takes the same amount of effort to explain any of the possibilities, you don’t get something for nothing, and backwards compatibility is an important feature of fortran. It is about the same level of effort as why #include <stdio.h> is the first line of a C program, or why #!/bin/sh is the first line of a shell script.
It is not “eliminate implicit typing”, it is more like “eliminate implicit mapping” or simply, to make implicit none the default.
Those who wish to include implicit none statements in their program units for eternity, have at it - your only risk is the peers and posterity not looking kindly at the approach.
One has to wonder how long will it take for Fortranners to realize how mind-numbingly inane and sheepish it has been to impose on each other the “rule” to include the statement in every program unit and go way overboard as shown below and following it ad nauseum which makes Fortran appear nothing but ridiculous:
Please, stop trying to impose it on others. There are teams out there who just don’t want to have to type implicit none in every program unit should they be authoring new codes and also not have to resort to any compiler settings that vary from processor to processor.
If the overwhelming advice everywhere is to adopt implicit none and it has been the case since MIL-STD 1753 from 1978, the consensus among practitioners is clearly the good practice with Fortran is to adopt explicit declarations.
More than four decades later, surely Fortran can do with the good practice being the default.
This can be a basic consideration in terms of vision for modern Fortran starting with the next revision.
The following are actual scenarios, not hyperbole.
There are teams who are looking at new codes toward large scale simulators that can literally involve tens of thousands of modules and countless unit tests toward some of the major shifts that are on the horizon e.g., the energy sector globally moving toward a non-fossil fuel future. That C++20 and later revisions with its own module facilities is the likely programming choice in most circumstances is besides the point. Should modern Fortran have been the lingua franca for such technical computing, a default of explicit declarations will be highly beneficial. At comp.lang.fortran, you can notice a thread mention a simulator with a Fortran engine with 850,000 lines of code. This will be mid to small-size app in comparison to what is in the works.
Just like kernel32.f90 provided by Intel in their oneAPI product with interfaces to Windows C/C++ APIs, a team I had worked with had pursued a Fortran app which called for interfaces to proprietary libraries with a C interop layer; hundreds of functions were involved in the interfaces. Certain costly errors ensued, many of which could have been caught early on had implicit none been the default in the interface body.
As mentioned by several who are actually coding earnestly at present, moving to an implicit none as the default is far more likely to be beneficial and help catch/resolve bugs than it will harm by breaking any existing code.
Please stop with the ad hominem. I have nothing personally to gain here whatsoever. Just like Intel not adopting the recursive procedure as default but expecting users to do something explicitly to get the Fortran 2018 standard behavior, I don’t expect any compiler san LFortran to make implicit none the default. Nonetheless it will be really good for Fortran to advance toward explicit declarations, that is all I think.
So, in short, what is your solution about the implicit none situation?
PS.
Sorry for a naive question. Can this implicit none situation be solved in the compiler level?
I mean, the compiler will check,
if (`implicit none` and/or legacy stuff 'implicit real (A-H)' exist) then
! as is
else if (a variable is used however its type is not defined) then
! throw an error, say the type of the variable is not defined.
endif
Does that solve the implicit none situation you mentioned?
The solution is to revise one sentence in the standard (c.f. 18-007r1 document as proxy) which is in section 8.7 IMPLICIT STATEMENT page 114, paragraph 3, lines 32-34. Change it to something along the lines of:
“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”
This one change will help achieve implicit none become the default.
Relatively low cost change to those working on the Fortran standard body, massive benefit in the long-term for users.
If the solution does not have any side effects. Then just approve it. What is the problem?
I mean you may start a thread and ask people to upvote for this solution.
Although I do not feel implicit none is an issue, if your solution have no side effects, then I guess we can upvote for you.
But I do need the compiler to throw an error to me, if any variable’s type is not defined.
The issue is the large teams request Fortran move in a direction where implicit none indeed becomes the default. That does not stop anyone who wants to include implicit none from doing so. But it frees up from the standard perspective to those who don’t see the need for implicit mapping as default and who no longer want to support it.
