(j3.2006) Why did we do this?

[malcolm at nag-j.co.jp]

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.

Not to mention that this would be a gather-scatter operation,
so not trivial to implement (especially asynchronously).

>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.

Cheers,
-- 
.........................Malcolm Cohen, NAG.