[comp.lang.fortran] Pointers to array sections

guest@stat.fsu.edu (a guest account) (06/18/89)

If the standard really requires that pointers be able to point to
arbitrary array sections, then there is not much need for the (deleted)
SET RANGE feature.  Since SET RANGE would presumably be used when you
want to access a particular array section repeatedly, setting up
pointers to the appropriate sections in the RANGE group would not be
difficult. Not smart, perhaps, but not difficult....  It is easy to
imagine that a compiler could do a much better job optimizing a static
ALIAS than a run-time POINTER for this task.

The ALIAS, IDENTIFY, POINTER, and SET RANGE options all overlap
somewhat. (Quiz: which of the above are in the current draft
standard?).  It is not clear that the most general mechanism (the
extended pointers?) is the most reasonable or efficient.  I think
Algol-68 is a good example to how a very orthogonal language is not
necessarily the most comprehensible.  Using the same pointer paradigm
for array section aliasing and recursive data structures seems more
likely to confuse than clarify the code.
--
John D. McCalpin	mccalpin@masig1.ocean.fsu.edu

jlg@lanl.gov (Jim Giles) (06/19/89)

From article <750@stat.fsu.edu>, by guest@stat.fsu.edu (a guest account):
> [...]
> The ALIAS, IDENTIFY, POINTER, and SET RANGE options all overlap
> somewhat. (Quiz: which of the above are in the current draft
> standard?).  It is not clear that the most general mechanism (the
> extended pointers?) is the most reasonable or efficient.  [...]

No!  Neither characterization is clear.  What _is_ clear is that pointers
are lower-level mechanisms.  The lower-level construct allows the user to
simulate much of the other functionality (but not all - try to alias the
_diagonal_ of a two-d array with the pointer mechanism - can't be done).

The purpose of using higher-level mechanisms is for optimizations.  For
example, the RANGE mechanism allows someone to alias an array section
_and_nothing_else_!  The compiler may find the constrained semantics of
the construct useful in deciding dependencies and eliminating non-optimal
assumptions from the code.  Since a pointer can point to _anything_, the
compiler must generally assume that it _does_.