Readers interested in GCC/gfortran, please see this thread at comp.lang.fortran for what is in effect a letter from a long-time GCC/gfortran contributor, Paul Richard Thomas, to @shahmoradi : there is a lot to note for anyone willing to contribute to the GCC/gfortran development.
Dear Amil,
While Steve and I have been involved for a long time, I must play tribute to the founding trio, who built gfortran from scratch to the point, where it was a viable f95 compiler and was worth the efforts of successive waves of maintainers: Andy Vaught (for the front end, which produces the intermediate representation), Paul Brook and Steven Bosscher (for the translation of the intermediate representation to TREE_SSA, which then plugs into the gcc infrastucture). Toon Moene’s support on the gcc Steering Committee and testing to destruction of gfortran has been invaluable from the start.
Work started on gfortran, or g95 as was before the branch, in 1989. The first gcc ChangeLog is 2002 and is dominated by Paul and Steven. Steve Kargl’s first entry is in June 2003. Of the presently active maintainers, Thomas Koenig, Jerry Delisle , Francois-Xavier Coudert and I do not appear until 2005. 2004/5 saw a large growth in the number of people contributing patches so that by the mid-naughties gfortran’s f95 coverage was solid. Major f2003 features began to appear in the last half of that decade, with Daniel Kraft introducing the FINAL declaration in 2008, Janus Weil introducing polymorphism in 2009 and Parameterized Derived Types by me in 2017. Polymorphism and OOP steadily improved in a few years after it’s introduction to the point where it could be relied upon. Finalization received a big boost in 2012 with Tobias Burnus’s monumental “finalization_wrapper” but implementation remains incomplete to this day and is awaiting my recently posted patch for completion of Daniel and Tobias’s work. I fear that, as described earlier in this thread, implementation of PDTs is fundamentally flawed. Thus it is unlikely that full f2003 compliance will be achieved until some time in 2023!
One might reasonably ask why there has been such a slow development towards f2003 compliance, even. I might be speculating somewhat but it seems to me that it is largely, for the main part, due to the motivation of the volunteer maintainers to add or improve features that are compatible with commercial vendors’ offerings and reasonably reliable in all platforms. As the number of such features has fallen away, so have the contributors to gfortran. With a few exceptions, nearly all the work on gfortran since 2002 or 3 has been done on a voluntary, unpaid basis to meet immediate needs required to support specific coding needs. Such has been the weak demand for much beyond f95 that many of the commercial vendors ceased or slowed development and then fell by the wayside. Familiarity with C++ and/or the appearance of the likes of python meant that OOP support in gfortran grew relatively rapidly, the demand for consistent support for finalization has really only surfaced in recent years and PDTs are lagging further behind.
Thus, in my humble opinion, the “new generation of gfortran contributors” will only emerge if they are motivated either by need or are being paid to support gfortran. We give every assistance that that we can to newbies but our ability to do so is typically limited by our daytime jobs. That the gfortran compiler is written in C, with a tiny touch of C++, has also proven to be a barrier. All my younger colleagues are brought up to write their codes in Matlab/Octave or python and only delve into fortran when they have to and so the pool is ever diminishing.
If anybody wants a helping hand to write patches to fix bugs or add new features, please write to the gfortran list or get in touch with Jerry Delisle to join us on https://gfortran.cloud.mattermost.com/.
Best regards
Paul