(j3.2006) Select Rank

[Van Snyder]

Bill Long wrote:
> On Feb 18, 2015, at 2:55 PM, Van Snyder <van.snyder at jpl.nasa.gov> wrote:
>
>   
>> SELECT RANK would need two different forms if we were to allow it both for
>> assumed-rank and known-rank entities.
>>     
>
> For SELECT TYPE, we allow only polymorphic selectors.  I see no valid reason for allowing anything other than assumed-rank selectors for SELECT RANK.  The current consensus to borrow from SELECT TYPE and use an associate name, and include the selector in a SELECT RANK statement in the list of allowed uses of assumed-rank, seems clean and simple.  Lets keep it that way.
>   

The only reason to allow SELECT RANK for known-rank entities is its 
potential use in INCLUDE files, where one doesn't know the rank of 
objects whose names appear within the file.  I believe 04-195 is a 
superior solution to these problems.

The case I had, where I need the first element of an object whose name 
appears in an INCLUDE file, would be handled by allowing A(lbound(a)) as 
a subscript.  LBOUND(A) has the same extent as the rank of A, so (at 
least in this case) one wouldn't even need a RANK intrinsic function.  
Without 04-195, one needs different syntax for every rank, which brings 
us back to SELECT RANK for known-rank objects.

That leaves the problem of specifying the shape of the <selector> in a 
CASE block in a SELECT RANK construct -- if we decide to do it at all.