[J3] [EXTERNAL] Re: Limitations of SELECT RANK?

[Vipul Parekh]

On Tue, Oct 20, 2020 at 2:59 PM Mark LeAir via J3 <j3 at mailman.j3-fortran.org>
wrote:

> To give a little better context to Tom's question.
>
> On the fortran-proposals Github, we were discussing select rank and how
> one would need to generate nested select ranks equal to the number of
> assumed rank arrays in an array expression.
>
> For example, let's say we want to compute b1 = b1 + b2 + b3 (where b1, b2,
> and b3 are all assumed rank arrays). Let's also say the programmer knows
> that the rank of the arrays must be rank 2 or 3. Today, they would have to
> write something like the following:
>
> subroutine add_arrays(b1, b2, b3)
>
> real :: b1(..), b2(..), b3(..) ..
>

 To Mark and also Tom,

In the case of addition and similar operators, ELEMENTAL seems to me to be
the better solution in actual codes.  And Fortran has long supported this
crucial functional programming aspect as you know.

So then, what are the situations, realistic use cases, and scenarios for
rank genericity where ELEMENTAL will not suffice?  I think the great
challenge and the need for us in the /Generics subgroup is to establish
this clearly.

It will help, I think, to put forth fully worked out code from current
working codebases (or those under development) - stripped to a certain
level of compactness without losing context - that illustrates how
Fortranners go about their needs with TYPE, KIND, and RANK genericity needs
currently, either by duplicating code or via by employing far more
verbosity than is indicated by Formula Translation and/or by the facilities
available with other languages and computing paradigms in scientific and
technical computing.

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