(j3.2006) Why did we do this?

[Van Snyder]

malcolm at nag-j.co.jp wrote:
> 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.
>>     
>
> Actually, I would say that they *are not* simple things.
>
> The bounds and type parameters of alloc/ptr components are not
> required to be constant - indeed the bounds are not even permitted
> to be constant - and so those values form part of the value
> of the type as a whole.  This is entirely lost if one merely
> expands it as a list of components.
>
> As a user, expanding such a type into its components would be a
> hindrance to me, not a help - it would encourage mistakes to be made.
>
> Van Snyder claimed:
>   
>> 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.
>>     
>
> And would nonetheless be almost useless since the tree structure 
> would in no way be represented in the output.
>   

In the case of output of objects with length type parameters, the tree 
structure has to be represented by a conspiracy of the I/O list and data 
in the file.  Recursive types are a little bit more difficult, but not 
impossible once pointers are thrown out the window.
> Not to mention that this would be a gather-scatter operation,
> so not trivial to implement (especially asynchronously).
>   

The problem for objects of types with length parameters is also a 
gather-scatter operation.

>   
>> unformatted I/O of types that have 
>> allocatable ultimate components, including ones that aren't allocated
>>     
> ...
>   
>> ought not to be difficult for a processor to handle
>>     
>
> Au contraire.
>
> If it's too hard for the user to write the output he actually
> wants, it is even harder for the processor to implement what
> that user wants plus all the edge cases that no-one really wants
> but which people would fall into if such things were valid.
>   

It's impossible for the user to write what he actually wants if the 
object has private components.  The processor can write and read such 
objects if they don't have allocatable components.  I believe it would 
be possible to write and read objects that have private allocatable 
components, if the standard were to require it.

> Cheers,
>