# Tsoding on Fortran **URL:** \ **Category:** Uncategorized\ **Created:** [July 6, 2023, 3:01pm UTC](https://fortran-lang.discourse.group/t/tsoding-on-fortran/6102 "2023-07-06T15:01:37Z")\ **Posts on this page:** 1\ **Showing post:** 26
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [July 12, 2023, 4:06pm UTC](https://fortran-lang.discourse.group/t/tsoding-on-fortran/6102/26 "2023-07-12T16:06:40Z")
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: 1. intrinsic `STRING` type that, in addition to **jagged** arrays, could be used with character data processing with the intrinsic procedures in Fortran 2023 for `CHARACTER` type including `SPLIT`, etc. including the methods envisioned with erstwhile Part 2 of the standard with `ISO_VARYING_STRING` (now deleted), 2. intrinsic `BITS` type, 3. and a companion **unsigned integers** - see proposal(s) by GCC FOSS volunteer Thomas Koenig [**here**](https://github.com/j3-fortran/fortran_proposals/issues/2), 4. Good support for Generics which allows generic procedures, generic containers, and accessors to “contained” data 5. Proper enumeration type facility 6. Interoperability with C - already included in current or upcoming standard 7. Enhanced OO support with the ability to author inextensible types 8. IEEE support - already covered reasonably in current or upcoming standard 9. Improved error handling, say similar to floating-point handling introduced with signals and methods with `IEEE` support in #8 above but which extended to error scenarios generally. Meaning, KISS principle and **not** the challenges and cons with `try..catch..` type of exceptions 10. Enhanced functional programming - mostly covered by the upcoming standard with its `SIMPLE` procedures but which also includes `CONSTEXPR` functions 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](https://en.wikipedia.org/wiki/Bootstrapping_(compilers))** 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. --- _[View the full topic](https://fortran-lang.discourse.group/t/tsoding-on-fortran/6102)._