22-120r2 Generics formal requirements: usage/notional syntax?

[zjibben]

After yesterday's discussion on 22-120r2, I thought github issues would be a better vehicle for discussing different angles in parallel. I'll make a couple issues with some questions I have. First up:

https://github.com/j3-fortran/generics/blob/4e273a9b394a0e48a217fcf307c0ddb598475dd2/J3-Papers/Generics_Requirements.txt#L102-L117

This is orthogonal to the requirement E, but the notional syntax has me thinking. Did I understood yesterdays discussion correctly, that usage might involve renames, and look something like:

instantiate tmpl(integer(kind=int32)), get_ith => get_ith_i4
instantiate tmpl(integer(kind=real64)), get_ith => get_ith_r8
instantiate tmpl(cats), get_ith => get_ith_cats
instantiate tmpl2(integer(kind=int32), integer(kind=int32)), map => map_i4_i4
instantiate tmpl2(cats, dogs), map => map_cats_dogs

integer(kind=int32) :: i, j, ints(10)
real(kind=real64) :: reals(10)
type(map_i4_i4) :: intmap
type(map_cats_dogs) :: catdog

i = get_ith_i4(ints, 3)
j = get_ith_r8(reals, i)
call intmap%xxx
call catdog%xxx

[tclune]

One problem is that the paper on GitHub is of necessity out of date now. Once the paper is on J3 there are intellectual property issues with putting it back on GitHub. (At least I think I've heard that in the past.)

But to the technical aspects of your issue: Yes. In the specs paper this is described. It did not seem appropriate for the REQUIREMENTS paper, as it is just a "make it work well" rather than any particular use case that is driving this.

But ... the best practice would instead be for TMPL to have something like this inside:

   TEMPLATE TMPL (...)
       INTERFACE  GET_ITH
            MODULE PROCEDURE GET_ITH_T
       END INTERFACE
       ...
     CONTAINS
         FUNCTION GET_ITH_T(...)
          

This would obviate the need for rename in this context. That would not solve all possible conflicts (esp. with derived types) of course. But a useful thing to mention.

[zjibben]

One problem is that the paper on GitHub is of necessity out of date now. Once the paper is on J3 there are intellectual property issues with putting it back on GitHub. (At least I think I've heard that in the past.)

I didn't know that, thanks for the heads up! For what it's worth, I haven't read the version here on github more than was necessary to quote sections I had read from J3.

the best practice would instead be for TMPL to have something like this inside:

Ah, that's a big improvement to usability, compared to renaming. I think the renames would still be necessary for containers though. Not much way around that.

At first glance I was really irked by the need for a block of instantiate statements, instead of instantiating in-line with declarations and function calls. Bill sounded troubled by this as well. As I acclimate to it though, I'm not sure it's a terribly big difference to readability, especially once function calls are in an interface:

instantiate tmpl(integer(kind=int32))
instantiate tmpl(integer(kind=real64))
instantiate tmpl(cats)
instantiate tmpl2(integer(kind=int32), integer(kind=int32)), map => map_i4_i4
instantiate tmpl2(cats, dogs), map => map_cats_dogs

integer(kind=int32) :: i, j, ints(10)
real(kind=real64) :: reals(10)
type(map_i4_i4) :: intmap
type(map_cats_dogs) :: catdog

i = get_ith(ints, 3)
j = get_ith(reals, i)
call intmap%xxx
call catdog%xxx

vs

use tmpl
use tmpl2

integer(kind=int32) :: i, j, ints(10)
real(kind=real64) :: reals(10)
type(map<integer(kind=int32), integer(kind=int32)>) :: intmap
type(map<cats, dogs>) :: catdog

i = get_ith<integer(kind=int32)>(ints, 3)
j = get_ith(reals, i) ! Infer from arguments?
call intmap%xxx
call catdog%xxx

[tclune]

I too would prefer the inline notation, but subgroup so far has found that this would be very difficult to do.

But it would be a good time to re-examine this based upon our most recent work. When we rejected the above, it was when we were still looking at parameterized modules.

Being clunky is Fortranic. :-)

[zjibben]

I can certainly imagine inline notation would involve far more and deeper changes to the standard...