[J3] Standard conformance of parameterized derived type usage

[Van Snyder]

On Wed, 2020-11-11 at 10:25 +0900, Malcolm Cohen via J3 wrote:
> Well, it's standard-conforming, but opinions differ as to whether it is
> reasonable code.
> 
> The same question can be asked with KIND type parameters btw.
> 
> As it defines an infinite recursion with different type parameter values at
> every level, it is not unreasonable for a compiler to reject it on the
> grounds that it doesn't have infinite memory to store the descriptors. (Yes,
> there are techniques to handle this, but they perform worse for the cases
> when one is not doing an infinite recursion.)

The processor isn't expected to allocate an infinite list hanging from
the component when the object is allocated, or when the component is
allocated, or when the component of the component is allocated, or,
.... That's the program's responsibility.  So the recursion is only
potentially infinite. That has nothing to do with the type parameters.
One could define a type that doesn't have a type parameter for the
pointer component, and still have an equally infinite recursion. I
don't know of any processors that have a problem with a simple self-
recursive type.

> I did not find a compiler that did not either give a nonsense error, an
> internal error, a "we haven't done this yet 'cause it's too hard" error, or
> garbage output. One did both garbage output for LEN, internal error for
> KIND.
> 
> BTW the output should obviously be 0, 1, 2.
> 
> However, given the amount of "good stuff" that everyone has to implement,
> one would have to be sympathetic to the view that handling a definition of
> an infinite recursion of different type parameter values would be very low
> priority on the "to do" list.
> 
> Perhaps a more interesting question is whether it *should* be valid Fortran.
> It's not that it is impossible to implement, but it is certainly a lot of
> complication for little to no gain. I am sympathetic to that argument too.

I understand that what William originally asked for would require the
processor to do more work during allocation.

> 
> Cheers,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20201110/270b50b2/attachment.htm>