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

Vipul Parekh parekhvs at gmail.com
Tue Oct 20 11:44:39 EDT 2020


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20201020/877460a7/attachment-0001.htm>


More information about the J3 mailing list