Richard Maine wrote:
>
> Aleksandar Donev writes:
> > I am going to ask a "why so" F95 question again, and hope the answer is
> > not the dreaded "just because".
>
> Nah. I think there are actual answers to this one. Indeed, it is a
> question that has been asked several times...though it is possible
> that they were on comp.lang.fortran instead of here. I forget what
> happens where (and I frequent clf more than this list).
>
> > Fortran 95 says that two or more part references with nonzero rank must
> > not be specified in a structure component.
>
> Yep. You can't have arrays of arrays. One big reason that I recall
> is that there are two obvious ways of doing it. They are
> incompatable, and different choices are "obvious" to different people,
> or even to the same person in different applications. So claiming
> that the right choice is obvious (to you) doesn't actually help.
>
> > type point3D
> > real :: coordinates(3), data(2)
> > end type point3D
>
> > type(point3D), dimension(10) :: points
> ...
> > points[1:2]%coordinates[:]
>
> > It seems to me the second one should produce a rank-2 array section
>
> And would that be of shape (/2, 3/) or (/3, 2/)? There's the rub.
> There are arguments for both. Either way is going to confuse someone.
>
> Seems to me that last time this came up, Dick Hendrickson mentioned
> another reason also....but I've forgotten it again (or possibly
> confused this with a different question).
>
I don't remember for sure, but I think one reason was to avoid having
more than seven subscripts in an array reference by using several
components with several dimensions each. There didn't seem to be
a clean way to resolve this. Limiting the total to only seven
seems artificial (as do many other things) and allowing more than
7 is inconsistent with normal non-component-arrays. Allowing more
than 7 for normal arrays is likely to be non-portable. Picking a
number (like 15) is portable, saying "processor dependent" isn't.
That, coupled with the ordering problem, meant there didn't look
like there was an obvious thing to do.
Also, I forget the details, but I think you can dig a deeper hole
if in the above example, you make "coordinates" itself be a derived
type that has components that are arrays that have components that
are arrays.... I don't remember the problem, but I think you could
come up with situations that were ambiguous (at least to normal
humans, if not to the parser.)
Dick Hendrickson
> --
> Richard Maine | Good judgment comes from experience;
> [log in to unmask] | experience comes from bad judgment.
> | -- Mark Twain
|