# Simple Generics **URL:** \ **Category:** Uncategorized\ **Created:** [June 11, 2023, 5:54pm UTC](https://fortran-lang.discourse.group/t/simple-generics/5973 "2023-06-11T17:54:25Z")\ **Posts on this page:** 8\ **Page:** 2
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [June 14, 2023, 1:53pm UTC](https://fortran-lang.discourse.group/t/simple-generics/5973/21 "2023-06-14T13:53:50Z")
> [@everythingfunctional](#): > > … The general sentiment was that phrases/behaviors that are “implied,” “as-if,” or “automatic” are not really “Fortranic.” … @everythingfunctional , Thank you for your efforts, hope there is great success in coming up with simple semantics and simple syntax for Generics, that will be a boon for the language and its practitioners. Please note it is most disheartening to read "The general sentiment was that phrases/behaviors that are “implied,” “as-if,” or “automatic” are not really “Fortranic.”. Readers will note Fortran will be truly dead in the water without it, the adoption of modern Fortran, as in the changes heralded starting Fortran 90 - would have been negligible without this, the entire edifice would have collapsed. I am so taken aback by this I don’t know if the list is in the right order of conveying the importance, but readers will note: - a `module procedure` is _as if_ an explicit interface becomes available automatically for `USE`rs - working with objects of `ALLOCATABLE` objects is _as if_ an automatic garbage collection is taking place, - with a nonpointer actual argument with `TARGET`, a received argument of `POINTER` attribute and `INTENT(IN)` becomes automatically associated with the actual argument, - in the case of a `generic-name` of an interface body the same as that of a specific procedure, the disambiguation still occurs _as if_ performed automatically based on the rules in the standard, - in the case of a `generic-name` of an interface body the same as that of a derived type definition, the distinction between variable reference and structure constructor(s) still occurs _as if_ performed automatically based on the rules in the standard, - data initialization using the `DATA` statement is **as if** the object is automatically imparted the `SAVE` attribute, - variable definition in the variable declaration statement is **as if** the object is automatically imparted the `SAVE` attribute, - eschewing the `=> procedure name` in derived type definition of a type-bound procedure is _as if_ the procedure name is the binding label - … These are but a few things which immediately occur to me as I process the above-expressed sentiment, not all are directly relevant in terms of the context here and the desired goal of Generics with simpler semantics and syntax but the sentiment applies. That is, Fortran ultimately has to be **for** the practitioners, for simple and efficient practice by them. While **strong concepts** , if really done well, can be beneficial for the practitioners of Fortran and which can then imply **not a penny less** on the part of the effort a practitioner has to occur to define templates, **not a penny more** too has to come in strongly in the sense a practitioner should not have to expend any extra effort than absolutely necessary to define the template. In the simple case raised by @certik in the GitHub proposal with a generic function, this premise is not being met - hence the concern. P.S.\> @certik ./ any moderator of this Discourse: it might make sense to move all the comments in this thread related to Generics to a separate one, say titled “Simple Generics”? ---
**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\ **Post date:** [June 14, 2023, 3:03pm UTC](https://fortran-lang.discourse.group/t/simple-generics/5973/22 "2023-06-14T15:03:18Z")
I moved the comments into a new thread “Simple Generics”. @FortranFan I think it’s best to prototype and play with actual code and get some experience. Let’s implement the simpler generics for kind as “syntactic sugar” and see. Let’s iterate on the design. ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [June 14, 2023, 4:28pm UTC](https://fortran-lang.discourse.group/t/simple-generics/5973/23 "2023-06-14T16:28:07Z")
> [@certik](#): > > I think it’s best to prototype and play with actual code and get some experience. Let’s implement the simpler generics for kind as “syntactic sugar” and see. Let’s iterate on the design @certik, Thanks. I agree in principle though in practice given the realities of Fortran with its nearly 70 years of legacy, particularly with its standard, one almost two Fortran 2018 conforming processors to prototype. Does `LFortran` currently support the following standard-conforming snippet? ```fortran module m interface sub module procedure sub end interface contains subroutine sub() print *, "Hello World!" end subroutine end module ``` Thanks, ---
**Author:** ![PierU](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/pieru/32/1848_2.png) [@PierU](https://fortran-lang.discourse.group/u/PierU)\ **Post date:** [June 13, 2023, 6:17am UTC](https://fortran-lang.discourse.group/t/simple-generics/5973/24 "2023-06-13T06:17:08Z")
> [@tyranids](#): > > but I am not sure how to go about that really in a way that won’t draw ire from the (majority?, at least) many champions of backwards compatibility. Thanks avoiding this kind of unpleasant thinking, which only serves to create divisions. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [June 13, 2023, 8:59am UTC](https://fortran-lang.discourse.group/t/simple-generics/5973/25 "2023-06-13T08:59:02Z")
> [@tyranids](#): > > I would be happy to have ‘integer, kind’ extended to somehow indicate a variable-in-source-but-known-as-constant-at-compile-time value. It’s very reasonable to not want new keywords for every new feature, but I am not sure how to go about that really in a way that won’t draw ire from the (majority?, at least) many champions of backwards compatibility. I do not see a problem with backwards compatibility for this use of the KIND attribute. Rather, my concern might be that this is similar (almost identical) to the way the KIND attribute is used in parameterized data types (PDT). PDTs were introduced in the language in f2003, and there are even now, 20 years later, major compilers that do not support them, even partially, at a usable level for programmers. Both PDTs and templates for generic programming seem like they would be very useful for programmers, but if the implementation is so difficult that it cannot be done in a practical way, even after 20 years, then perhaps this approach should be discussed from this perspective. Is it some aspect of this KIND attribute that has caused the long delay of PDT implementations? ---
**Author:** ![certik](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/certik/32/4_2.png) [@certik](https://fortran-lang.discourse.group/u/certik)\ **Post date:** [June 14, 2023, 6:48pm UTC](https://fortran-lang.discourse.group/t/simple-generics/5973/26 "2023-06-14T18:48:09Z")
> [@FortranFan](#): > > ```auto > module m > interface sub > module procedure sub > end interface > contains > subroutine sub() > print *, "Hello World!" > end subroutine > end module > > ``` I just tried it and it doesn’t work yet, reported at: [Support module procedure inside interface · Issue #1821 · lfortran/lfortran · GitHub](https://github.com/lfortran/lfortran/issues/1821). ---
**Author:** ![FortranFan](https://avatars.discourse-cdn.com/v4/letter/f/96bed5/32.png) [@FortranFan](https://fortran-lang.discourse.group/u/FortranFan)\ **Post date:** [June 17, 2023, 8:18pm UTC](https://fortran-lang.discourse.group/t/simple-generics/5973/27 "2023-06-17T20:18:24Z")
Any and all readers interested in Generics made simple should also read the following “papers”: 1. [https://j3-fortran.org/doc/year/18/18-116.txt](https://j3-fortran.org/doc/year/18/18-116.txt) 2. [https://j3-fortran.org/doc/year/18/18-281r1.txt](https://j3-fortran.org/doc/year/18/18-281r1.txt) 3. [https://j3-fortran.org/doc/year/23/23-159.txt](https://j3-fortran.org/doc/year/23/23-159.txt) Note the author @longb mentions in the 2nd “paper” the email by a long-time GCC FOSS volunteer and a `gfortran` compiler developer, Paul Richard Thomas: ![image](https://global.discourse-cdn.com/free1/uploads/fortran_lang/original/2X/7/7ccdb8e96c19c7cbb0f7c9b562a511fb61de44e9.png) ---
**Author:** ![septc](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/septc/32/77_2.png) [@septc](https://fortran-lang.discourse.group/u/septc)\ **Post date:** [June 18, 2023, 1:07pm UTC](https://fortran-lang.discourse.group/t/simple-generics/5973/28 "2023-06-18T13:07:30Z")
> [@FortranFan](#): > > Any and all readers interested in Generics made simple should also read the following “papers”: I think it would be great if there is a centralized thread (in this Discourse, not on Github) that collects such generics-related documents in one place, such that people do not have to search around many places for related information. Then any people can add new links or URL as needed, so it is easy to update / modify the thread. Also, one useful “rule” in that thread may be “no discussion / arguments here”, i.e., the purpose of that thread is limited to just collect the related materials / texts (and possibly cite the key ingredients, as in the above post). [Previous page](https://fortran-lang.discourse.group/t/simple-generics/5973.md?page=1)