Templates for functions/subroutines

[certik]

A very common request is to allow templates for subroutines or functions, in order to allow code like the following:

    <T> function f(x)
    <T>, intent(in) :: x
    f = x + 1
    end function

instead of

interface f
    module procedure f_int
    module procedure f_single
    module procedure f_double
end interface

contains

    integer function f_int(x) result(f)
    integer, intent(in) :: x
    f = x + 1
    end function

    real function f_single(x) result(f)
    real, intent(in) :: x
    f = x + 1
    end function

    real(dp) function f_double(x) result(f)
    real(dp), intent(in) :: x
    f = x + 1
    end function

More use cases available at https://github.com/certik/fortran-generics.

[arjenmarkus]

I have written a proposal on templates that uses a very different approach. It was inspired by a note on the subject of generic programming features already in Fortran (to be published with ACM Fortran Forum, but a draft can be found at http://flibs.sourceforge.net/generic_programming_features.pdf). I will add the note as a new issue.

[certik]

@arjenmarkus thank you, that would be great if you send it. There are a lot of approaches here, and the committee is looking at all approaches and it wants to get something done for 202y (the standard that comes after 202x, which will be the next standard)

[certik]

@arjenmarkus your pdf references the paper from Magne Haveraaen, who sits next to me right now. We'll discuss your paper today and I'll report back.

[arjenmarkus]

Small world :). Regards, Arjen Op do 17 okt. 2019 om 18:10 schreef Ondřej Čertík <notifications@github.com

…

: @arjenmarkus <https://github.com/arjenmarkus> your pdf references the paper from Magne Haveraaen, who sits next to me right now. We'll discuss your paper today and I'll report back. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4?email_source=notifications&email_token=AAN6YR6FS6TXJRCF3XIORLTQPCFAZA5CNFSM4JBFWSXKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBQVAQQ#issuecomment-543248450>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN6YR7O7Q2NYEBKG5L2M5DQPCFAZANCNFSM4JBFWSXA> .

[cmacmackin]

I agree that templates are desperately needed. They should be applied to derived types as well as to procedures. I remember coming across a proposal from some time ago for "parameterised modules", which I thought looked quite promising, but nothing ever came of it I guess. (I see you have an example of something like that in your fortran-generics repository and it is by far the cleanest syntax of those you show).

I will say that I'm rather tired of the committee perpetually pushing this onto the standard after next. The two most recent releases have been relatively minor revisions, so it's not as though the decision was made to focus elsewhere. People have been wanting this feature for years and it really is crippling to development. If this is pushed back until 202y then we likely won't see widespread compiler support until the 2030s. We'd almost be better off trying to back a newer language like Chapel, which does include these features, in that case.

[certik]

@cmacmackin thanks for the feedback here and the other issues, we really appreciate it. I am new to the committee, this is my second meeting. I am still learning about what the committee did in the past and the history behind various proposals. The way I see it is that this is a requested feature, and we should try to get it right and included. If the committee wasn't moving as fast in the past, then here is what we can all do to help:

1. Join the committee (like I did --- if you can at all, please join, so that you can help push these proposals forward)

2. Help us figure out a good way to do generics in Fortran, then help us write a good proposal, and help us advocate for it

To help with 2., I created this repository, and we are trying to keep it updated with the proposals that the committee is considering. Regarding generics in particular, I will keep updating this issue on the latest status. This will go into 202y, as we do not have any good proposal that is ready to go into 202x, and it is important to get this right. The committee needs help, and my experience with organizing open source communities such as SymPy makes me hopeful that opening up the commitee's work to the wider community will allow us to organize ourselves more efficiently. If you have other ideas what the committee can do to improve, please let us know.

[marshallward]

Templating would strongly support our current development efforts at GFDL. I am a contributor to the FMS framework used by weather and climate models at GFDL (including my main job of MOM6 development), and it relies heavily on preprocessing of template-like code for many interface functions, such as for MPI operations.

Some example code is below, where a file is #included multiple times, each time replacing MPP_TYPE_ and similar macros with different types, size, and rank (scalar, 2d, 3d, etc.):

• Interface definitions:
  https://github.com/NOAA-GFDL/FMS/blob/2cd5dc6dc601c1238bbabdf1440b2057f957795b/mpp/mpp.F90#L680-L725

• Repeat #include statements of the above functions
  https://github.com/NOAA-GFDL/FMS/blob/2cd5dc6dc601c1238bbabdf1440b2057f957795b/mpp/include/mpp_comm_mpi.inc#L1033-L1159

• The low-level call to MPI:
  https://github.com/NOAA-GFDL/FMS/blob/master/mpp/include/mpp_sum_mpi.h

• Mid-level interface for different array ranks:
  https://github.com/NOAA-GFDL/FMS/blob/master/mpp/include/mpp_sum.inc

This does work, and has worked for a long time, but it's a lot of bloat and gets even more complicated when trying to manage some of the conditional support for things like complex numbers and non-default kinds for integers or reals.

I feel like this must be a common problem, and it would be great to find a template-like solution which can unify this sort of code.

[FortranFan]

@cmacmackin thanks for the feedback here and the other issues, ..

Thanks to @cmacmackin for frank comments.

@certik, it'll be most useful and beneficial if there is a way to (almost) force WG5 and ALL its member body representatives to read user feedback. You may note your great initiative for GitHub Fortran proposals was immediately noticed online e.g., comp.lang.fortran - see this thread there:

And some of the comments there:

• "Personally, it's very sad that various features are postponed or even rejected for this round of revision (which may be reasonable for the committee for various reasons), and I'm (very personally) sad that a builtin "string" type seems not considered even as a revision candidate
• "in 2019, people will use C++ instead"
• "Exception handling was planned to be introduced in Fortran 90 (called then Fortran 8X) but was rejected due to complexity. Since then, this feature has been proposed several times but never accepted."
• "I was expecting that these two features (at least, generic programming) were the main target of F202X (according to the last survey and some documents available online)."
• "my question is: What is the set of "most compilers" supposed in ..?" That is, in WG5 papers N2167 and N2168
• "My concern is that some compilers seem very slow to catch up with new features. Initially, I imagined that this may be due to the difficulty of implementation. But more recently, I strongly feel that this is also due to the policy or direction of a company (e.g., investment). If the latter is a more major factor for one compiler, I am afraid that "waiting for most compilers to catch up" could mean "forever" in practice..."

There is a lot to learn from the comments by practitioners of Fortran.

[FortranFan]

A very common request is to allow templates for subroutines or functions, in order to allow code like the following:

    <T> function f(x)
    <T>, intent(in) :: x
    f = x + 1
    end function

instead of

interface f
    module procedure f_int
    module procedure f_single
    module procedure f_double
end interface

contains

    integer function f_int(x) result(f)
    integer, intent(in) :: x
    f = x + 1
    end function

    real function f_single(x) result(f)
    real, intent(in) :: x
    f = x + 1
    end function

    real(dp) function f_double(x) result(f)
    real(dp), intent(in) :: x
    f = x + 1
    end function

More use cases available at https://github.com/certik/fortran-generics.

Considering the semantics and syntax for generic interfaces were introduced way back in Fortran 90 and were simplified further in the latest 2018 revision as follows:

  generic :: f => f_int, f_single, f_double

contains

  integer function f_int(x) result(f)
     integer, intent(in) :: x
     f = x + 1
  end function

  real function f_single(x) result(f)
     real, intent(in) :: x
     f = x + 1
  end function

  real(dp) function f_double(x) result(f)
     real(dp), intent(in) :: x
     f = x + 1
  end function

and keeping in mind how much of the semantics for PGAS SPMD approach toward parallel computing was achieved using [..] notation in COARRAYS. a key aspect to deduce perhaps is the importance of conveying semantics via syntax and focusing on the latter. Sure this can run counter to the current work process of Fortran standard development: get the use cases, generate requirements, then develop specifications, and finally the syntax. For concepts that are well-established in computer engineering widely such as generics and that are so well-known now and where every new language that crops up has sophisticated support for generics from the get-go or soon thereafter (e.g., Julia and Haskell), may be the approach should be the other way around? Settle on syntax that conveys to the coders and processors of Fortran all they need and allow the semantics to simply fall out of that?

Say the language introduces an attribute 'TYPE' with the existing statement of GENERIC: why can't the following convey for a processor everything it needs to setup generic interfaces for the 3 types shown in the original post here?

  function f(x) result(r)
     generic, type :: T => int, real, real(dp)
     type(T), intent(in) :: x
     type(T) :: r
     x = x + 1 
  end function

Is committee overthinking this and needlessly procrastinating the development of generics in Fortran?

[certik]

@marshallward thanks for the feedback! Yes, every code has an MPI layer like yours and we all struggle with the lack of templates for this one. We might not need full templates for this one, perhaps just some better way to handle arbitrary arrays and types. But the committee is well aware of this use case, as almost any parallel Fortran MPI code faces the exact same issue.

I will keep you involved on this effort if you are interested. Tom Clune is leading this template effort, he will send instructions soon and I will update this issue once he does.

[certik]

@FortranFan thanks for the encouragement. If you don't mind, why don't you open a new issue or new issues, put [META] in the title and let's discuss there how to best organize ourselves. So that we can keep issues like this one for pure technical content regarding this particular issue.

[certik]

@FortranFan I created the meta issue at #26. Let's discuss the workflow there.