(j3.2006) Vipul Parekh's post in comp-fortran-90

[Bill Long]

> On May 31, 2017, at 2:01 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
> 
> Vipul Parekh posted a question in comp-fortran-90 that makes me believe
> we need an interp concerning recursive relationships between types using
> allocatable components.  His example was
> 
>  type :: t
>    type(t), allocatable :: next
>  end type t
>  type(t) :: foo
>  foo = t(foo)
>  print *, 'Is foo%next allocated? ', allocated(foo%next)
> 
> For this example, I'd say the print statement ought to print F

Agreed.

But I don?t understand why he didn?t try the obvious:

allocate (foo%next)
 
if the goal is to allocate foo%next. 

> 
> But in this example
> 
>  allocate ( foo )

foo is not allocatable according to the declaration type(t) :: foo.

The ?recursion? here is on the name of the type - having an allocatable component of type(t) in the definition of type(t).  Similar pointer components are also allowed.  

Cheers,
Bill


>  foo = t(foo)
> 
> it appears that there is a cyclic relationship between foo and itself
> using its next component.  It depends upon whether foo is deallocated
> before t(foo) is evaluated.  If it's not, there is a cyclic
> relationship.  I believe one of the goals of the initial design of the
> ALLOCATABLE attribute was to prevent cyclic relationships.
> 
> It might be necessary to add to the requirements for assignment to an
> allocatable variable that it is deallocated if it has any allocatable
> components.  This might be too strong.  For example, it would prevent
> walking down a linked list using
> 
>  foo = t(foo%next)
> 
> A possibility for this example is to interpret it as
> 
>  type(t) :: temp
>  allocate ( foo )
>  call move_allocate ( foo, temp )
>  foo = t(temp)
> 
> But it's not obvious that scenarios using multiple recursively-connected
> types don't still result in cyclic relationships.
> 
> This will need some deep investigation.
> 
> Althogh I'm the one who proposed to allow recursive relationships
> between types using allocatable components, maybe we ought to remove it.
> 
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425