To: J3                                                     J3/23-184
From: Malcolm Cohen
Subject: More rank-independent functionality
Date: 2023-June-13
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.

    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.

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