[J3] Rank-agnostic array element and section denotation

[Van Snyder]

There was objection to using a character to indicate rank-agnostic
multi-dimensional array-element and section denotation, which was
proposed in 19-150 and accepted, and for which specifications were
provided in 20-113 and edits were provided in 20-125r1.

Specs and syntax were passed, with objection.

Edits that implemented those specs and syntax failed.

Objections appear now to have been poorly thought through.

The proposed alternative was a derived type. Presumably, it would have a
rank-one integer array component, probably (preferably) not private.
For the processor to verify that the number of subscripts specified by
the object is a constant, and to know to how many dimensions of an
object it applies when it is used as a subscript, the size of that
component would have to be specified by a kind type parameter.

To use an entity of that type as a subscript, the entity would need to
be


      * a named constant of the type, 
      * a variable of the type, 
      * a function whose result is of that type, or 
      * a constructor of the type.


Providing a value for a named constant would require using the
constructor, which use would require providing a constant for its kind
type parameter.

Providing a value for the variable would require either using the
constructor, which use would require providing a constant for its kind
type parameter, or reference to the component.

Using an expression for the subscript, as opposed to using a variable or
named constant, would require using the constructor, which use would
require providing a constant for its kind type parameter, or using a
function whose result is of that type, one function per rank. Generic
resolution could not be used because function result characteristics do
not participate in generic resolution.  Therefore, the function form
would not be rank agnostic and could not be used in a parameterized
module or template or other generic-programming solution.  With macros,
one could put uses of it inside a macro-time case selector.

Consider as example the use of an array that includes space for a halo
gotten from other images.  Consider a reference to the "interior" of the
array, that belongs to the current image.  The syntax proposed in 20-113
and implemented in 20-125r1 would be something like


        A(@lbound(a)+1:ubound(a)-1) = ....


Assuming the type is named something like Multi_Dimensional_Subscripts,
one would use something like


        use ISO_Fortran_Env, only: Multi_Dimensional_Subscripts
        A(multi_dimensional_subscripts(rank(a))(lbound(a)+1):multi_dimensional_subscripts(rank(a))(ubound(a)-1) = ....


Of course, one could rename the type to a different name in every
scoping unit, so that one doesn't know what is going on without looking
back a hundred or thousand lines to the USE statement, and provide a
differently-named named constant for the rank in every scoping unit,
allowing


        use ISO_Fortran_Env, only: M => Multi_Dimensional_Subscripts
        ....
        integer, parameter :: R = rank(a)
        ....
        A(m(r)(lbound(a)+1):m(r)(ubound(a)-1) = ....


or


        use ISO_Fortran_Env, only: M => Multi_Dimensional_Subscripts
        ....
        integer, parameter :: R = rank(a)
        type(m(r)) :: L, U
        ....
        l = m(r)(lbound(a)+1)
        u = m(r)(ubound(a)-1)
        ....
        A(l:r) = ....


The contention that this is somehow better -- easier to write, easier to
read, easier to understand, less expensive to maintain -- than the
proposed syntax is rather difficult to believe.

I hope that those who voted against the specs, syntax and edits will
reconsider, and vote to pass 20-125r1 at the next meeting.  Or provide
an alternative that is better -- easier to write, easier to read, easier
to understand, less expensive to maintain -- than the proposed syntax,
not just some vague "I don't like this" knee-jerk and handwaving.

The "@" sign before a multidimensional subscript is necessary to
distinguish between vector subscripting and multidimensional
subscripting.  Consider a rank-three array A and two rank-one extent-two
arrays V1 and V2.  In


        A(V1,V2)

is V1 a pair of subscripts, one for each of the first two dimensions of
A, and V2 a vector subscript for the third dimension, or is V1 a vector
subscript for the first dimension, and V2 a pair of subscripts, one for
each of the last two dimensions?

The "@" sign before a multidimensional section subscript is not strictly
necessary.  That could be eliminated (or made optional) to simplify the
proposal.

As proposed in 18-119 section 2.4.1 (page 27), A(V) was allowed, with
the rank of V allowed to be greater than one, and the first extent of V
a constant the same as the rank of A.  The result is an array having
rank one less than V and extents given by extents of V after the first
one.  If the ranks of A and V are both one, and the extent of V is one,
it becomes ambiguous whether the result is a scalar or an array, so "@"
would be needed.  If the extent of V is greater than one, it is a vector
subscript and the extent of the result is the same as the extent of V.
If the rank of A is greater than one or the rank of V is greater than
one, there is no ambiguity and the "@" would not be needed.  The
proposal in 19-150 did not include the proposition that the rank of V
could be greater than one.

A pessimist sees the difficulty in every opportunity; an optimist sees
the opportunity in every difficulty.
  -- Winston Churchill


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20200306/c782431c/attachment.htm>