(j3.2006) Why did we do this?

[Van Snyder]

Dick Hendrickson wrote:
> This came up on comp.lang.fortran a few weeks ago.  I think the answer
> is that the allocatable or pointer elements don't have to be simple
> things.  They can be derived types with allocatable or pointer
> components.  Think about the pointer to the head of a linked list, or
> worse, a circular list or tree.  You can do linked lists with either
> pointer or allocatable components.  So, how does the processor know
> when to stop expanding the pointer/allocatable thing into it's sub
> parts?
>   

With allocatable there's no problem.  The graph of allocatable ultimate 
components is necessarily a tree.  It can't have any cycles, or indeed 
can't re-join into an arbitrary DAG.

It would be useful to allow unformatted I/O of types that have 
allocatable ultimate components, including ones that aren't allocated, 
so as not to require (a) putting every ultimate component explicitly in 
the I/O list, and (b) not requiring every ultimate component to be 
public.  It ought not to be difficult for a processor to handle this.  
Formatted input would be a different story, because the processor hasn't 
had the opportunity to write a data structure it understands, as it 
would for unformatted output, which is the only kind of unformatted 
(non-stream) input the standard expects a processor to understand.

The problems with pointer ultimate components remain, whether they're 
associated, disassociated, or undefined, so no change is possible (or 
desirable) for them.

> Dick Hendrickson
>
> On Tue, Jul 5, 2011 at 12:44 AM, Van Snyder <van.snyder at jpl.nasa.gov> wrote:
>   
>> [10-007r1:217:22] says "If an input or output item {in an I/O list} is
>> allocatable it shall be allocated."
>>
>> [218:1-5] goes on "If an item of derived type ... the list item is treated
>> as if all of the components of the object were specified in the list in
>> component order; those components ... shall not be pointers or allocatable."
>>
>> If the program listed the components explicitly, the allocatable or pointer
>> ones would be allowed.  If the processor splits them out into components in
>> component order, they're not allowed.
>>
>> Why did we do this?
>>
>> I do see a problem with I/O for derived type objects with allocatable
>> pointer components, the problem being that the processor doesn't
>> automatically split the object into its components if any of the components
>> are pointer or allocatable.  It only does this if any component would be
>> processed by a defined I/O procedure.
>>
>> If objects of derived type were treated as a list of their components, in
>> component order, if any of them are pointers or allocatable, the problem
>> goes away?
>>
>> Why did we do this?
>>
>> We didn't prohibit objects of types with length components from appearing in
>> I/O lists.
>>
>> _______________________________________________
>> J3 mailing list
>> J3 at j3-fortran.org
>> http://j3-fortran.org/mailman/listinfo/j3
>>
>>     
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>