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

[Clune, Thomas L. (GSFC-6101)]

Bill,

That’s my general agenda here.    I’m not so much seeking the change to SELECT RANK as I am seeking (strong) arguments against that path.    I’ve not yet read Reinold’s post.  Doing that shortly.

- Tom



> On Oct 20, 2020, at 11:53 AM, Bill Long via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> It seems like the objectives below are directly solved by templates, rather than tinkering around with existing constructs. 
> 
> 
> 
>> On Oct 20, 2020, at 10:44 AM, Vipul Parekh via J3 <j3 at mailman.j3-fortran.org> wrote:
>> 
>> 
>> 
>> On Tue, Oct 20, 2020 at 9:10 AM Reuben D. Budiardja via J3 <j3 at mailman.j3-fortran.org> wrote:
>> 
>> Can the compiler not expand this appropriately at compile time so that 
>> the appropriate resolution can be done at compile time?
>> 
>> In Tom's original example, the two constructs are equivalent. So if 
>> compiler can do the first construct in principle it can do the second 
>> one, except the second one is simpler / easier for the programmer to write.
>> 
>> Or am I missing something obvious? ..
>> 
>> Good question, Reuben.  That's exactly what I would like to know also.
>> 
>> Tom can correct me if I'm wrong, but my understanding is Tom's question is in the context of the Generics effort.  In this specific instance, how to go about introducing better *rank genericity* in Fortran.
>> 
>> In my simple-minded thinking, the primary motivation for Generics is in *avoiding code duplication*.  Code duplication, as you all know, is extremely costly in more ways than one.  It leads to what is said in Generics literature as "Slow Programmers".
>> 
>> Tom's original example with Fortran 2018 SELECT RANK illustrates such duplication.  Whether with type, kind, or rank genericity, Fortranners know it's often possible for them to *expand* out their methods (e.g., library procedures) in their library code with the constraints they in mind (in Tom's instance: 1D to 3D) and present it to their consumers in APIs that appear to be Generic superficially.  However this comes at great and often immeasurable cost
>> 
>> So the question really is why can't the Fortran processors do this *expansion* for the practitioners.  The inquiry on RANK(1:3) subscontruct in a SELECT RANK construct is part of this bigger question.
>> 
>> Vipul
>> 
> 
> Bill Long                                                                       longb at hpe.com
> Engineer/Master , Fortran Technical Support &   voice:  651-605-9024
> Bioinformatics Software Development                      fax:  651-605-9143
> Hewlett Packard Enterprise/ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425
> 
> 
> 
>