Some thoughts on PDTs

[Paul Richard Thomas]

Dear Thomas,

Ahem!

> after Jerry's implementation of DTIO, only PDTs are
> missing as a major F2003 feature from gfortran.
>

2016-08-22  Paul Thomas  <pault@gcc.gnu.org>
                 Jerry DeLisle  <jvdelisle@gcc.gnu.org>

     PR fortran/48298

I did the most of the front-end and Jerry the library. We have both
provided "after sales service" to our respective contributions. Jerry
has had the harder time of it because the library part is rather more
complicated, especially where namelists and their ilk are concerned.
For this reason, Jerry is still troubled by bugs in the
implementation.

Ranting aside, PDTs are indeed missing but we still have an F95
feature that is poorly implemented, namely pointers to components of
arrays of derived types. This was going to be fixed by the array
descriptor work on fortran-dev but, following a burst of activity at
the end of last year, it has stalled again. I posted a fix for pointer
array components but this was met with silence, presumably because gcc
was in stage 4. My inclination is to extend this fix to all such
pointer arrays by moving the 'span' variable from a hidden derived
type field to the array descriptor, thus fixing this problem properly
once and for always.

> I'd like to share some unordered thoughts on a way to
> implement these.  Comments, corrections etc. are the whole
> point of this mail, so very highly welcome :-)
>
> To recap: A PDT could look like
>
> TYPE matrix (k, n)
>   integer, kind :: k=4
>   integer, len :: n
>   real(k) :: a(n,n)
> END TYPE matrix
>
> with a later declaration of a type that is actually usable as
>
> TYPE (matrix(k=selected_real_kind(15),n=100) :: mymatrix
>
> What changes would we need for the internal data structures?

I believe none. The actual/formal arglist structures can be recycled
to handle the parameters within the compiler.

>
> We would probably have to extend gfc_symbol with a list of type
> parameters, including defaults. During resolution, we could then
> instantiate the new type.  This sound doable in principle (but I am sure
>  that there are quite a few traps and pitfalls). This would work
> for a static variable.
>
> Things will get more interesting for an allocatable or pointer
> variable or  dummy argument which is a PDT.
>
> Apparently, the kind number has to be a constant expression, which
> makes things a bit easier.

Funnily enough, it is the kind parameters that make life rather more
difficult, since derived types have to be instantiated for every
combination of kind parameters that arise in compilation. Of course,
these derived types can be "hidden" and their names used to drive the
instantiation process.

Thus, for your example below, k1=4 and k2=8 might generate a derived
type with name _foo_4_8. Instantiation then might proceed along the
lines:

generate PDT name from variable declaration
look for PDT in symtree
if it exists
  use it
else
  generate new smbol and use that

Length parameters are rather easier. The 'users' of these parameters,
such as the arrays 'a' and 'b' below can be handled as if they are
allocatable and they can be initialised/finalised using the deferred
variable mechanism in trans-decl.c

>
> Still, to pass a variable of a type like
>
> TYPE foo(k1, k2, n, m)
>   integer, kind :: k1
>   integer, kind :: k2
>   integer, len :: n
>   integer, len :: m
>   real(kind=k1), dimension(n,m) :: a
>   real(kind=k2), dimension(2*n,m) :: b
> END TYPE foo
>
> we would need some new type of descriptor.  It is not totally clear to
> me at the moment what data this would need to contain, or how it would
> look like.

I don't believe that a new descriptor is needed for PDTs.

>
> Any ideas?  Or did anybody of our esteemed colleagues from the other
> Fortran compilers who have already implemented PDTs publish anything on
> the matter?
>
> Just some thoughts...
>
>         Thomas

As you might have gathered, I have been giving this some thought.
Given that the vendors that have delivered PDTs all say that it was
the most difficult F2003 feature, most of my thinking as been to look
for the minimum effort route.

Regards

Paul


-- 
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein