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

[Bader, Reinhold]

Hi, 

some time ago I wrote
https://github.com/j3-fortran/fortran_proposals/issues/144
which (admittedly in a limited way) might solve the problem in question.

Regards
Reinhold

-----Ursprüngliche Nachricht-----
Von: J3 <j3-bounces at mailman.j3-fortran.org> Im Auftrag von Clune, Thomas L. (GSFC-6101) via J3
Gesendet: Dienstag, 20. Oktober 2020 17:27
An: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Clune, Thomas L. (GSFC-6101) <thomas.l.clune at nasa.gov>
Betreff: Re: [J3] [EXTERNAL] Re: Limitations of SELECT RANK?

(I started writing this before Bill’s most recent post came in.  But I think it is still relevant.)


The focus on what is equivalent to what is a bit misleading from my perspective.  Technically the syntax in the example which started this thread is currently disallowed.   What it is equivalent to is therefore contingent on a change to the standard.         I am _strongly_ in favor of retaining the requirement that generic resolution is at compile time, so Malcolm’s “equivalent” is not the path I was intending.  

We are seeing that common use cases for SELECT RANK have duplicate text.      Aside from generic resolution, there are also cases involving whole array arithmetic.   For these cases,  the shorthand in my example is not just convenient for the coder, but is also a means to reduce errors that can happen when a subsequent change is only propagated to a subset of the RANK clauses.   Granted, this is the weakest case of code duplication, as the duplicates would all line up next to each other in a single file.

Reading between the lines, what I’m hearing (and what I seem to recall from the earlier discussion) is that while it is relatively easy for a human to interpret the example below as equivalent to the expanded form, and not much of a stretch to envision a preprocessor performing the expansion explicitly,  it is difficult/nontrivial for the compiler to do the same and/or that the modifications to the standard would be deceptively difficult.     I’m willing to grant either or both of those concerns, but it would be useful if that could be explained just a bit more fully.

The only comment that I will now add in response to Bill’s last post:

>> 
>> In Tom's original example, the two constructs are equivalent.
> 
> No, not the way the standard is written. RANK(1:3) has no meaning specified in the standard.   I think what you are wanting here is a new syntax rule that allows multiple ranks to be specified (all different - no repeats allowed) and have the semantics be specified so that the syntax represents multiple RANK statements, one for each of the specified ranks, and with the identical BLOCK replicated for each.   In the end, the compiler needs to see only ONE rank value for a particular block.  

This argument applies to Malcolm’s response as well.  RANK(1:3) has no meaning specified in the standard.  No one is debating that.   And yes, what some are asking for is a new syntax rule.    


> Otherwise, the whole point of SELECT RANK is missed. 

Understood.   Some of the discussion on the GitHub thread has gone further,  but I thought it useful to first gain some understanding of the difficulty of what is proposed here.  

Cheers,

- Tom