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