@shahmoradi , nice write-up. Indeed there is no battle. Also, absolutely no battle of any kind is envisioned in the functioning of Fortran standard development workflow with the few “national bodies” that contribute to the work. The functioning is almost as if Fortran for the sake of itself and which is almost separated from the concepts of time and space! This can be seen as quite “spiritual” indeed. But there is a problem though, there is no clear vision, almost no purpose, and from direct experience, please note there is little to no objectivity whatsoever.
The end result is that practically every point in time, especially since ANSI X3.9 1966 revision, Fortran falls much further short than what it can be in terms of its semantics, syntax, and services (its features, etc.) when it comes to the full realization of computing needs in any science and/or engineering endeavor. This is just not right by those scientists and engineers, it’s tremendous disservice to them. The worst part is this is even more true today that before and no one at the helm is showing much of any leadership nor objectivity.
The way language enhancements work is like this, it entirely depends on who makes the requests and how, otherwise it’s “no enhancements for you”. Then when the domain of scientific and technical computing notices many a codebase (Glmnet) migrate away to other options, note the incoherence, inconsistency, and inadequacy of Fortran language evolution too have played a crucial role in the defection. To not acknowledge this reality and to do little to nothing to enhance the development workflow but rather to always deny, deflect, and delay is the very antithesis of being objective.
To give you a simple but what I consider to be absolutely relevant to modern scientific and technical computing is enum types. Such computing inevitably has to deal with magic numbers and few computing solutions now hesitate to offer rather extensive type-safe facilities to their practitioners to deal with such numbers via enums. You will know what is viable with C++, C#, D, Julia, MATLAB, Python, Rust, Swift, Visual Basic, and so forth. Fortran added something nominal but mostly type unsafe in 2003 revision. It’s trying again with Fortran 202X. Lo and behold then, Fortran gives not one but two facilities under the charter of “user-defined types” but which would appear foreign to those used to the other one, derived types. So on the anvil is stuff such as the following:
enum, bind(C) :: flags
enumerator :: f1 = -1, f2, f3
end enum
and also
enumeration type :: flags
enumerator :: f1, f2, f3 !<-- enumerator members CANNOT have user-defined values!!
end enumeration type
when neither of which offer much of any facility beyond C circa Kernighan-Ritchie late 1970s and Pascal 1980!
Imagine a language as resource-constrained as Fortran brings in not one but two different syntactical forms of a facility with different semantics that are both deficient for modern needs. How insane is that!? Wait until the confusion for the practitioners!
This is being asleep at the wheel and dreaming of 1960 thru the 1980s to serve as platforms for mid to late 21st century needs. Nothing objective here.