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

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

Damian,

Yes that is a possibility, but my current thinking that such a change is at best a side note for generics.   Something akin to templates could avoid the need for SELECT RANK entirely in many use cases, including the one that prompted this thread.    The focus seems to keep slipping away from the fact that I’m actually looking for arguments as to why the SELECT RANK approach would be difficult to implement (in the standard and/or compilers).    This would help me to refocus the discussion in the other forum.

Note that the requirement would probably not be stated as requiring the "compiler to generate …”.    I would imagine it would be something more like “provide a mechanism to allow a single block of code to apply to multiple ranks within a SELECT RANK construct.”

- Tom







On Oct 20, 2020, at 2:48 PM, Damian Rouson via J3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>> wrote:



On Mon, Oct 19, 2020 at 7:38 PM Malcolm Cohen via J3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>> wrote:
It’s exactly identical to

   IF (RANK(arr)>=1 .AND. RANK(arr)<=3) CALL SUB(arr)

There is no “limitation” in SELECT RANK here.


I wonder if another way to say the same thing is that requiring the compiler to generate the equivalent code amounts to a generic programming requirement.  It's therefore appropriate to include such a proposal as part of a new generic programming facility, but it's unlikely to succeed on its own while the development of generic programming requirements are already well under way.

Damian

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