Imagine a Fortran language version, say Fortran 95 - a version for which quite a few relatively bug-free, stable, and highly optimizing compilers were/are available, and that already included (not true, but imagine so) about 10 or so features, some that were introduced in later revisions:
- intrinsic
STRINGtype that, in addition to jagged arrays, could be used with character data processing with the intrinsic procedures in Fortran 2023 forCHARACTERtype includingSPLIT, etc. including the methods envisioned with erstwhile Part 2 of the standard withISO_VARYING_STRING(now deleted), - intrinsic
BITStype, - and a companion unsigned integers - see proposal(s) by GCC FOSS volunteer Thomas Koenig here,
- Good support for Generics which allows generic procedures, generic containers, and accessors to “contained” data
- Proper enumeration type facility
- Interoperability with C - already included in current or upcoming standard
- Enhanced OO support with the ability to author inextensible types
- IEEE support - already covered reasonably in current or upcoming standard
- Improved error handling, say similar to floating-point handling introduced with signals and methods with
IEEEsupport in #8 above but which extended to error scenarios generally. Meaning, KISS principle and not the challenges and cons withtry..catch..type of exceptions - Enhanced functional programming - mostly covered by the upcoming standard with its
SIMPLEprocedures but which also includesCONSTEXPRfunctions for enhanced compile-time programming.
All 10 of above were within reach of Fortran by the 1995 revision given its rich legacy boosted by the brilliance of Backus and team with the optimizing compiler breakthrough back in the 1950s and high-level language improvements and advances in CS since.
Alas, many of the above facilities never made it in to Fortran and many were late by decades.
But anyway, with such a Fortran language and stable compilers for it, the Community could have far more readily developed a boot-strapping compiler for Fortran in Fortran itself toward additional important features of this decade such as support for GPUs.
Consider most of the Fortran compilers now - it’s evident the number of Fortranners willing to work on the compiler development is grossly inadequate. The front-ends for most or all of them are in some variants of C or C++ and that is a massive barrier, too daunting or insurmountable for most Fortranners perhaps. However, consider many of the newer attempts such as the LLVM-based ones using modern C++. Starting with parsers, so much of the effort toward “lowering” the instructions to the LLVM level involves use of standard C++ containers, overwhelmingly - guess what!! - std::string, and some std::vector.
With a bit of vision, Fortran could have natively provided the facilities and which would INDEED have been used by both the language practitioners and processor developers including toward boot-strapping. That is the missed boat.
There is a part 2 to the notion of Turing-complete languages. Ideally one would want to hang one’s hat on a Turing-complete language or close to it for any serious coding endeavor. Similarly, a simple measure of the easy-of-use and productivity of a programming language is how feasible it is to author a boot-strapping compiler with the language itself. Fortran currently fails miserably in this regard and that is the root of the problem.
It is still not too late for Fortran is my contention. Accomplish a few basic extensions to the language and great things will happen.
And it is NOT a “zero-sum game”. This notion that “oh, Fortran really needs good portable support for GPUs - that’s the pressing need of the hour - and all this about string, bits, and implied save, and implicit none is a distraction” is entirely inane. Things go hand-in-hand. And it should be possible to do simple things simply using a tool and that’s when sound solutions for demanding challenges such as GPU programming shall become viable.
And with some vision and intent, advances can be worked on at the same time, or nearly concurrently.