To: J3 J3/23-184r1
From: Malcolm Cohen
Subject: More rank-independent functionality
Date: 2023-June-14
Reference: 23-167.
1. Introduction
Assumed-rank pretends to be a first-class Fortran concept, but much of the
functionality, or potential functionality, is only accessible by using not
just C interoperability, but a C procedure.
Similarly, we have some useful rank-independent functionality in F2023, but
more would be useful. Some of the Fortran 90 rank-independent technology
does not apply to scalars, only to arrays: it may be useful to extend
those.
2. Some proposals for consideration
These are mostly for assumed-rank, but some are for generic rank.
2.1 As selectors
An assumed-rank entity should be allowed to be the selector in SELECT
TYPE. The associate-name is likewise assumed rank.
2.2 As array constructor values
For assumed-rank (not associated with assumed-size), it would be very
useful to just flatten it to its elements in array element order.
2.3 In whole-array reductions
If we do 2.2, this would be available anyway as REDUCTION([arobj]),
but it would be more readable perhaps as REDUCTION(arobj).
And in that case, permitting the argument to a reduction to be
scalar really does make sense.
And if we allow a reduction on assumed-rank associated with a scalar
(and we ought to), for consistency we should also allow the reduction
on a scalar.
In particular, ANY, ALL, COUNT, IALL, IANY, IPARITY, MAXVAL, MINVAL,
NORM2, PARITY, PRODUCT, REDUCE, SUM.
MAXLOC and MINLOC would return a zero-sized array for a scalar, so they
are perhaps not so useful for assumed-rank, but probably useful enough
for generic rank that allowing it makes sense.
FINDLOC seems to be fine for assumed-rank, but useless for scalar.
The scalar case, and the "assumed-rank associated with a scalar" case,
are best handled with special case code. Possibly best to simply allow
it for scalar, even though that result would be useless (just to get
generic rank code to compile).
All of these don't work for assumed-rank associated with assumed-size;
it would be useful to that end to be able to enquire whether an assumed
rank entity is associated with an assumed-size array. Admittedly, we
can do this already with
SIZE(X,RANK(X))==-1
but IS_ASSUMED_SIZE(X) would be less cryptic.
CSHIFT works fine for scalar, but is terrible for assumed-rank as it
destroys compile-time generic resolution. Ditto EOSHIFT. So for
generic rank, maybe we should allow scalar, but assumed-rank is a
non-starter.
Similarly, reductions with DIM arguments would produce unknown-rank
results with assumed rank. This is quite simply not an option.
IS_CONTIGUOUS could be permitted for scalar (it already is for assumed
rank). For one-element arrays, IS_CONTIGUOUS is defined to be true, so
that seems to be a reasonable answer here.
LBOUND and UBOUND are already allowed for assumed-rank, and return a
zero-sized array when it is associated with a scalar, so permitting a
scalar argument seems harmless.
PACK is horrible, better just to allow [x] for x assumed-rank.
Note: PRECISION is already permitted for assumed rank, the standard is
misleading but not incorrect.
RESHAPE is already solved by permitting [x] for assumed-rank, but it
would be friendlier to permit it for scalar and assumed-rank (not
associated with assumed-size) directly. Some weasel-wording may be
needed.
SHAPE: this is clearly allowed for assumed rank.
SIZE: This should be allowed for scalar arguments for consistency
(it is already allowed for assumed rank).
3. Other proposals
For rank independence, other proposals such as looping have been suggested.
Nothing that has been a noticeable improvement on the existing technology
has yet to be discovered.
We should investigate potential improvements for looping over an assumed
rank object.
===END===