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

Clune, Thomas L. (GSFC-6101) thomas.l.clune at nasa.gov
Tue Oct 20 14:32:27 EDT 2020

Yes.  The INCLUDE statement is great except for all the ways in which it isn’t.

On Oct 20, 2020, at 2:11 PM, Van Snyder via J3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>> wrote:

On Tue, 2020-10-20 at 16:21 +0000, Steidel, Jon L via J3 wrote:

Tom wrote:

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.
End Tom

While there may be use cases that have duplicate text in multiple SELECT RANK case blocks, many involving whole array arithmetic, the code generated for each of the blocks is very different due to the difference in the array ranks between the two blocks. The compiler would have to replicate the block for each possible rank and generate a separate block for each rank. The ranks specified in the rank selector would need to be constant for this to happen, they could not be variable or values evaluated at runtime.


One easy way to get the same code in every block, and alert future maintainers that the code ought to remain identical unless there's a really good reason for it to be different is to use INCLUDE. It's been around since FORTRAN 77.

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

More information about the J3 mailing list