Dear Paul, First, I want to thank you for leading the PDT development efforts. It's a feat, especially given the unusual implementation complexities of PDTs.
Given that you have led much (or all) of the gfortran PDT development efforts, do you have any insights into the latest status of PDTs in gfortran 12 and its development timeline (in particular, fixing the kind type parameter bugs)?

I was redirected to this page by FortranFan (in response to my question about the status and the future of PDTs in gfortran here: https://groups.google.com/g/comp.lang.fortran/c/xwg5Ak-EwHc).

The kind type parameter is crucial for generic derived types and the existing PDT bugs in gfortran have slowed down the progress of our research project (other compilers have full nearly-bug-free implementations of PDTs), but we strive to keep the gfortran support along with other compilers.

I'd love to get involved and help the development of PDTs as much as my other obligations allow me. But in doing so, I need someone who can guide me (and others interested) along the way as I currently have zero experience with gfortran internals and the inner workings of PDTs. Perhaps this could be turned into a 2022 Google-Summer-of-Code project if it is not too late already.

Thanks again,
Amir S.

On Monday, January 1, 2018 at 12:07:41 PM UTC-6, paul.rich...@gmail.com wrote:
> On Sunday, 31 December 2017 04:10:14 UTC, FortranFan wrote:
> > On Saturday, December 2, 2017 at 2:27:49 PM UTC-5, paul.rich...@gmail.com wrote:
> >
> > > ..
> > > Apart from this, there are issues with type matching in interface comparisons ..
> >
> > @Paul,
> >
> > Thanks much for all your effort. Wish you many more retreats to enjoy that lead to many more blessings for the FOSS developers!
> >
> > Re: your comment above with "issues with type matching in interface comparisons", you may want to consider the test case below as well:
> >
> > --- begin code snippet ---
> > module m
> >
> > type :: t(ell)
> > integer, len :: ell
> > integer :: i(ell)
> > end type
> >
> > contains
> >
> > subroutine sub( a )
> > type(t(ell=*)), intent(inout) :: a
> > end
> >
> > end module m
> > ! main program
> > use m, only : t, sub
> >
> > type(t(ell=42)) :: foo
> >
> > call sub( foo )
> >
> > end
> > --- end code ---
> >
> > Upon compilation,
> > gfortran.exe -c p.f90
> > p.f90:20:18:
> > call sub( foo )
> > 1
> > Error: Type mismatch in argument 'a' at (1); passed TYPE(Pdtt) to TYPE(pdtt)
> Aaaah, its's the 'only' that has done that. I need to make sure that 't' is expanded to encompass the PDT instances in the USE statement.
>
> This is now PR83646.
>
> Thanks
>
> Paul

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