Of course! No one should take anything from this thread seriously. 
Except the punch_unit thing. That is real.
1 Like
Some non-mathematicians want i as a complex constant (0,1) e.g. physicists and engineers other than electrical ones who often use j for that.
Iām waiting for the LaTeX code to be put on GitHub and then Iāll get started editing it.
implicit double complex (i-j)
Easy peasy.
Many worked very hard with the /DATA subgroup on the J3 committee on what was US21 Typed enums feature but got overruled - particularly with Class (2) local identifier status for enumerators. And the end product out of the committee turned out rather flawed. That is bad for Fortran, really bad and that needs to be called out - no one needs to be offended about it and no one should feel entitled to a nonexistent right to be not offended for any reason.
In the noninformative text of the standard, deletion of implicit mapping - thus IMPLICIT NONE becomes the default - can be achieved by a relatively small change to the standard, perhaps even limited to a sentence as I suggest here.
a. Annex B is Informative section of the standard; the text here is informational in nature - the effort to include an additional sentence or two should be so ātaxingā the cost/effort estimate of this enhancement is all āwrongā - Fortran cannot have this, stop the press - yeah right!
b. The same applies to Section 4.3 i.e., on Compatibility, to add a clause to build on the existing wording such as āExcept for the deleted features noted in Annex B.1ā should be so taxing the cost/effort estimate of this enhancement is all āwrongā - Fortran cannot have this, stop the press - yeah right!
Ok, so if you have gfortran try compiling everything you need that is Fortran using the āwolfā command
#!/bin/bash
#@(#) wolf.sh - Without ol' Fortran: gfortran with compiler switches that prevent using some deprecated features
gfortran \
-ffree-form \
-ffree-line-length-none \
-fimplicit-none \
-fno-dollar-ok -fno-cray-pointer -fno-dec-structure -fno-dec-intrinsic-ints -fno-dec-static -fno-dec-math \
-nocpp \
-fno-dec \
-fmodule-private \
-pedantic-errors \
-Wimplicit-interface \
-Wall \
"${@}"
exit
G95 supports F, which was a try at cleaning things up from the compiler end; which for new code is not a bad idea. But honestly, most compilers have a switch to make āIMPLICIT NONEā the default.
Those will all be added to the implicit none (...) statement in Fortran 2057. In fact, the majority of code in a Fortran file will be implicit none statements. To accommodate this, the maximum line length will be increased to one million characters.
1 Like
Boy, thatāll be really tough: Fortran 202X just increased the maximum line length to 10,000 and itāll be a lot of added cost to the standard committee and the processors to raise the limit again over the next 30 years!
But not to worry, the standard is kind the IMPLICIT statement - other than none - can be repeated ad infinitum so that can do the trick for the practitioners.
The important achievement of Fortran 2057 shall be that IMPLICIT is a Turing-complete language in and of itself!
2 Likes
Well of course, with ISO_PERL_BINDING, weāll be able to shell out to Perl from within an implicit statement. Then thereās basically no reason to write actual Fortran code anymore. Perl can call Julia right?
1 Like
Well, apparently all should be a reserved word.
As you all know, God is real unless declared integer, therefore:
implicit integer (g)
but who on Earth would use such a boring expression, when it can beā¦ simplified as:
implicit integer except (a-f,h-z)
For better simplifications, except should be nested, so we could use even simpler, more sophisticated expressions, such as:
implicit none except all except none except integer all except (a-f,h-z)
The latter can be simplified even more by repeating the except clauses above, again and again for an eternity. 
4 Likes
Well I propose a new feature where you can join the definition of real, integer and whatever you like. It will be super power union.
implicit (real, integer, type(MyBoss)) (1-z)
and a variable will behave as an integer in an integer expression as real in a real expression without changing of course the bit pattern (only the first bits retained if there are more bits, and whatever is in memory if there are less).
The type of an expression being of course the type of the first variable evaluated by the processor (that we know is not specified by the standard).
2 Likes
We should start a new thread, āHow to make Fortran be like Forthā - Cobol is not āsimpleā enough for that. We could go even further with āHow to make Fortran be like the most elegant programming language aroundā - see the Hello World example implemented in the latter to realize how easier to understand it is, compared to Fortran. 
So, F205X will have fancy implicit nones but no forall statement, apparently 
This thread reminds me of this: The Worst Programming Language Ever - Mark Rendle - NDC Oslo 2021 - YouTube
1 Like
Eh? Jacob Williamsās
implicit double complex (i-j)
was not valid Fortran 77 and is not valid Fortran 2018. A standard-conforming way to get that effect in f90 or later is
implicit complex(kind(1d0)) (i-j)
But I would only want one of i,j to be (0,1) and I would want only one of i,j to be assumed complex, not every variable with a name beginning with i or j. I mistakenly thought that
integer,parameter:: wp = selected_real_kind(18)
implicit complex(wp) (i-j)
would be allowed, but declarations before implicit statements are not. Iām sorry for giving the impression that gfortran had a bug in this area. A parameter statement is not the same thing as a declaration of a parameter.
Thatās a good one butā¦ no mention of Fortran?
Because he tries to build the worst programming language. Fortran could only improve what he has come up with.
1 Like
I donāt know if God is real, but I have seen little evidence that they are rational.
\pi is transcendental and consequently irrational.
But 42 is an integer and consequently rational. 